Speed issues

[303factory]

Hi

My VB client links to a set of data tables that are stored on a shared network drive (the 'Z' drive). I develop it on my C drive (the local client) then distribute it for everyone to use with a server database (the live client)

Recently we've had complaints the live client is running really slowly, taking ages to open and close forms. Going through debug on a live client ive found the bottleneck is opening and closing recordsets. These happen far slower than on my local client

To close one screen and open another about 5 sets of recordsets will be opened and closed by code (my forms are not linked directly to tables). Each one will take about 1 second to open and 1 second to close. As such its taking at least 20 seconds to move from screen to screen.

What I'd like to know is what exactly could be causing such a slow opening/closing of recordsets.

Is there some drive latency I could investigate and hassle the IT deparment about?

Perhaps there is a cunning way I could combine all my recordset opening and closing into one move?

I appreciate this might be more of a networking question but I'm not experienced at networking or VB so if anyone has any suggestions that would be excellent.

 

[RuralGuy]

Do you have a persistant connection established?

 

[303factory]

Do you have a persistant connection established?

Yes I think so, if one person has the client open there is always an LDB file in the same folder as the MDB file.

 

[RuralGuy]

*Every* FrontEnd should maintain a persistant connection to eliminate any additional entries in the .ldb file. Everyone does have their own copy of the FrontEnd, right?

 

[303factory]

Do you have a persistant connection established?

Although I thought I had a persistant connection, I tried the 'bound form' solution on the link you gave me, and it seems to speed it up significantly!

One further question though, are there any risks keeping a persistant connection? Up to 10 staff will be logged onto the server file at once, will having a bound form on each or a global recordset left open increase the probability of corruptions or locked records causing bugs?

 

[RuralGuy]

One further question though, are there any risks keeping a persistant connection? Up to 10 staff will be logged onto the server file at once, will having a bound form on each or a global recordset left open increase the probability of corruptions or locked records causing bugs?

Should not be a problem.

 

[303factory]

*Every* FrontEnd should maintain a persistant connection to eliminate any additional entries in the .ldb file. Everyone does have their own copy of the FrontEnd, right?

Yes they all have the front end client. I'm going to build a version that keeps a persistant connection and distribute it! thanks peeps this has saved me much grief

303

 

[RuralGuy]

I start my systems with a hidden form that maintains the persistant connection to the "System" table that I use to log everyone off when maintenance is needed. The invisible form is the last to close so it is very handy for cleanup and other housekeeping chores.

 

[303factory]

I start my systems with a hidden form that maintains the persistant connection to the "System" table that I use to log everyone off when maintenance is needed. The invisible form is the last to close so it is very handy for cleanup and other housekeeping chores.

How do you log everyone off? If I want to update the server file or compact/repair etc I have to run aroudn asking everyone to close down access which is a bit of a pain! Is there a better way?

 

[gemma-the-husky]

look at ms knowledge base article 889588

specifically wrt "sharing violation" registry key

here's the link

http://support.microsoft.com/kb/889588/en-us

 

[RuralGuy]

How do you log everyone off? If I want to update the server file or compact/repair etc I have to run aroudn asking everyone to close down access which is a bit of a pain! Is there a better way?

I use one of the kick em off routines in Jeff's list.