Shared databases slow to open on XP network

  • Thread starter Thread starter Bruce
  • Start date Start date
B

Bruce

I have a LAN with 6 clients running an Access 2000 front-
end connecting to 4 shared back-end databases on a Win2000
server. The first 1 or 2 connect fairly quickly but the
rest can be quite slow to start & display the main menu.
The network is using a VPN Firewall router for dynamic IP
addresses. There is no DHCP or any other complicated
network setups. The front-ends detect the network drive
type (O: drive type 'Remote') very quickly but then seem
to load system values from one of the shared mdb files and
open the menu slowly. Is this a networking problem? (Jet
is on the latest release on all machines). WinXP SP1 on
all PC's. Help!!
 
Bruce said:
I have a LAN with 6 clients running an Access 2000 front-
end connecting to 4 shared back-end databases on a Win2000
server. The first 1 or 2 connect fairly quickly but the
rest can be quite slow to start & display the main menu.
Click to expand...

See the Access Performance FAQ at my website.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Bruce said:
I have a LAN with 6 clients running an Access 2000 front-
end connecting to 4 shared back-end databases on a Win2000
server. The first 1 or 2 connect fairly quickly but the
rest can be quite slow to start & display the main menu.
The network is using a VPN Firewall router for dynamic IP
addresses. There is no DHCP or any other complicated
network setups. The front-ends detect the network drive
type (O: drive type 'Remote') very quickly but then seem
to load system values from one of the shared mdb files and
open the menu slowly. Is this a networking problem? (Jet
is on the latest release on all machines). WinXP SP1 on
all PC's. Help!!
Click to expand...
 
I had that problem before and the way I solved it was by moving the files so
they weren't so far down in the directory structure.

They were like C:\dir1\dir2\dir3\dir4\db1.mdb

Weird, but it worked.
 
Dru Snyder said:
I had that problem before and the way I solved it was by moving the files so
they weren't so far down in the directory structure.

They were like C:\dir1\dir2\dir3\dir4\db1.mdb
Click to expand...

Yup, that problems been mentioned before but I'm curious. Was this a
performance problem for even the first user. Or just the second and
subsequent users?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Im still battling with this problem myself and its driving me nuts. For me
the first user can load it fine, but from there its a nightmare. Im creating
all the *.mdl files at load by using the top on tony's page which has helped
the matter somewhat but its still very very very slow to load. This is not
an issue with Win98. The Databases are just stored in the first dir.
C:\Dir1\*.mdb

Once its loaded, the applications run fine, relinlinking tables is
impossible with other users running the app, takes 20mins almost
otherwise!!! They all have to relink tables terminal by terminal, then it
takes the whole of 20 seconds. This is not a problem with Win98 sites so im
gussing that it has something to do with the network security in WinXP?

Regards,
Richard
 
Richard Krupa said:
Im still battling with this problem myself and its driving me nuts. For me
the first user can load it fine, but from there its a nightmare. Im creating
all the *.mdl files at load by using the top on tony's page which has helped
the matter somewhat but its still very very very slow to load.
Click to expand...

Presumably that was a typo and you meant *.ldb?
Once its loaded, the applications run fine, relinlinking tables is
impossible with other users running the app, takes 20mins almost
otherwise!!! They all have to relink tables terminal by terminal, then it
takes the whole of 20 seconds. This is not a problem with Win98 sites so im
gussing that it has something to do with the network security in WinXP?
Click to expand...

Yes, but the key here is once the link as been refreshed to the first
table, open a recordset against that table. then relink all the other
tables and close that recordset.

Even in A97 on Win 98 systems and server re linking is quite a bit
faster.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Yes i meant ldb :P
Yes, but the key here is once the link as been refreshed to the first
table, open a recordset against that table. then relink all the other
tables and close that recordset.
Click to expand...

Im doing all of that, but its made no difference.

Regards,
Richard
 
See the Access Performance FAQ at my website.
Tony
Click to expand...

Tony,

I read your FAQ (and other docs).

I am also trying to split a database to try to enhance performance
over a network.

I have a database with only a few hundred records in each table (many
related tables). The thing is, I have several users in California and
several users in Manila that I'm trying to deploy the database app to.
The database is in California; Manila users access it over the company
intranet. Originally, they ran from the MDB in California.

I tried splitting into a front-end and back-end MDB. The back-end is
on the network, the front-end I emailed to a user in Manila and he
copied it onto his desktop.

Even when a user clicks on a combo box that is populated from a table
with only a dozen records, my performance hangs. I'm not sure what I'm
not doing right, since I built the system with mostly wizards, with
tweaked code where needed. The tables I built by hand. My expertise is
in SQL, not VB (or VBA), so I don't know if there is any housekeeping
code that I need.

Any suggestions?

Steve Schacher
 
Back
Top