logging in takes 10 to 40 minutes

system · November 8, 2010, 12:51pm

Hi,

I’ve tried google and searching the site but can’t find an answer to this

when logging into reporter , supervisor or designer, either from the client pc or the server using the full client tools - it takes ages to log in, once I am past the login screen, today it’s taking users 40 minutes, its normally around 7 minutes.

here are the systems details and back ground

Running Business Objects 6.1b (6.1.021.2263)
Repository = SQL Server 8.00.760
Server = Microsoft Windows 2000 Advanced Server
Version 5.0.2195 SP 4 build 2195
VMware Virtual Platform
X86- based PC (4x processors)

this system was virtualised this year, and is not the cause of the login time issue as this has been happening for years I am told…

system originally set up to be an infoview server only, and has only 4 or 5 users, but due to a server move and other hardware issues the users now connect via 6.1 fullclient tools rather than via the webi tool…

There is no way we can turn the infoview system back on (we’ve tried)
and when the infoview service was working it used to log in straight away!

I believe this issue is related to the way the system was setup to deal with infoview requests/access rather than directly from the clients pc via odbc connections and sqlserver drivers which is what it is now doing, but what’s causing the delay when launching the application?

Additionally if you use an incorrect password or username you will get an instant error from the login screen, but use a correct combination you get the busobjs weclome splash screen for 40 minutes before the application then responds with the ritual “new report wizard”

please help, I have no knowledge of installing or repairing the 6.1 verson, especially the webi application.

abductee (BOB member since 2006-09-05)

system · November 8, 2010, 1:28pm

Supervisor, Full Client (in two-tier mode), and Designer all talk to repository directly, so the existence of a WebI or BCA server is not likely causing your problem.

Long logon times in the desktop apps is usually caused by a complex security model (that is, users exist in many groups, which in turn are members of many other groups). But even then, 40 is pretty significant. It has to be some issue in the database. I’d recommend that you have your DBAs watch the database while you initiate a logon process. They should be able to capture the individual queries that are taking the longest amount of time.

Joe

joepeters (BOB member since 2002-08-29)

system · November 8, 2010, 2:21pm

thanks Joe,

if anything the complex supervisor structure is much simpler since I’ve had access to it - its now just 2 groups, so I dont think its that. will try the DBA route again, I have been down that route before, but will try to get them to look harder this time.

I dont know if this helps but the reason the infoview no longer works is because it was set up with the repository on server A and the business objects services ran on server B whilst the IIS service ran on server C

now with the full client set-up (where I had to generate a new BOMAIN KEY) servers B and C are turned off and the clients just point directly to the repository on Server A

I’ve not had to do any reconfiguration other than generate a new bomain key, so maybe somewhere its still trying to talk to server B for somthing?

bu this has been the way for a few months so why the recent hike in logon time from 7 mins to 40 mins which seemed to happen over the weekend?

abductee (BOB member since 2006-09-05)

system · November 8, 2010, 3:11pm

The only time a desktop app will talk to a BO server is when you’re using Full Client in three-tier mode (ZABO); and then only if Full Client is launched from Infoview, or when using a bomain.key that was generated with ZABO. If you’re using a bomain.key that was generated from Supervisor, then it’s not looking for an Infoview server.

So you’re not using Infoview because the servers it was installed on went away. Good enough reason as any, I suppose

It must be database related. I don’t know much about SQL Server, but I expect there must be a way to capture the individual SQL statements that the client is sending to the server. If your DBAs can do that, then re-execute the statements in order, I’ll bet the cause of the problem will be quickly determined.

Joe

joepeters (BOB member since 2002-08-29)