Slow Loading

  • Thread starter Thread starter Dwight
  • Start date Start date
D

Dwight

What might be some causes for forms to load slower on 1
network drive compared to another.

I have 2 network drives that I have the same database
application on. My personal network drive loads very
quickly, but the office drive loads 20 times slower. Same
network, just a different drive.

Thanks in advance!
 
Dwight said:
What might be some causes for forms to load slower on 1
network drive compared to another.

I have 2 network drives that I have the same database
application on. My personal network drive loads very
quickly, but the office drive loads 20 times slower. Same
network, just a different drive.

What do you mean by same network? Are you talking about a local LAN, or a
WAN?

You can read about using ms-access on a wan here:

http://www.attcanada.net/~kallal.msn/Wan/Wans.html

If you are actually talking about the same network, but just a different
operating system on the host (such as win2000 vs win98), then usually
keeping a persistent connection open to the back end will restore
performance problems (that means your front end that resides on each pc
KEEPS a connection open at all times to the back end).
Check out:

http://www.granite.ab.ca/access/performancefaq.htm
 
I am talking about a LAN. MS Access is on the local PC.
The .MDB is on the LAN on a drive labeled F:\. It runs
great on that drive. The only problem is that I am the
only one in the office that can view this drive. When I
copy the .MDB to a shared drive I:\, it slows way down.
When I debug, I find that it is very slow before it ever
reaches the first line of code in an "On Open" event.

Dwight
 
I am talking about a LAN. MS Access is on the local PC.
The .MDB is on the LAN on a drive labeled F:\. It runs
great on that drive. The only problem is that I am the
only one in the office that can view this drive. When I
copy the .MDB to a shared drive I:\, it slows way down.
When I debug, I find that it is very slow before it ever
reaches the first line of code in an "On Open" event.

Dwight

Fine, but did you try the persistent connection idea? There are several
reasons why forcing a connection open can fix the performance problem.
Perhaps you do have a different security setting. Note that ms-access
actually tries to delete and create a locking file in that shared dir. By
forcing a connection open, you eliminate this large overheard, and as
mentioned, 9 out of 10 times it fixes the slow form loads. You REALLY want
to give this idea a try. This persisting connection idea means that you
network does NOT slow down to the speed of ms-access trying to create a
locking file (which can take a long time). So, don't jump the gun here and
assume that this persistence keep the file open trick will not solve your
problems (it might not help..but don't assume that because you don't have a
file open in your code that it will NOT fix your performance problem).

Other things to check would be is there any possibility that users don't
have the same full permissions in that dir (they need create, AND delete
permissions here!).

If the above forcing of the connection does not help..then fine..you can
then start going through that great check list at Tony's site. However, you
owe your self the 1 minutiae of testing that a persisting connection takes.
Further, do you have any code that re-links the tables? (again, the
persistent connection trick can speed this up by hundreds of times).

Anway, AFTER you try test the above suggesting, then the rest of that check
list is at:
http://www.granite.ab.ca/access/performancefaq.htm
 
Dwight,

I had a somewhat similar problem which was cured by unselecting "Track name
autocorrect info" under Tools>Options>General. My first machine was opening
the initial form in 20 seconds and the second machine was taking four or
five minutes. I deselected the option on both machines and both are loading
the form in about 4 to 5 seconds now. The description in the KB article
below did not exactly fit my circumstances but the solution worked never the
less.

http://support.microsoft.com/?kbid=200600

Lee Wrenn
 
Back
Top