Help: very slow Access

[Waldo Smets]

Hi,

We have Access 2000 installed on both clients and a server, with SP3. It's a
Windows 2000 network. I can't get my front-end to perform with acceptable
speed, and even when you just link some back-end tables to a new database on
a client, there is a delay in opening the (small!) tables...
The network, server and clients itself don't seem to be a problem
(performing well on other applications..). I've tried removing the
subdatasheets in the back-end, but that doesn't help.. Also checked that
permissions on the back-end folder where straightforward.. I'm out of
ideas..

Help!

Jerry

 

[MacDermott]

You might try this:
Create a mapped drive directly to the subdirectory on the server where
your backend data resides.
Use the Linked Table Manager to relink your tables, using the new drive
mapping.
This may improve performance for you.

HTH
- Turtle

 

[Joe Fallon]

Check out Tony's web site for lots of tips:
http://www.granite.ab.ca/access/performancefaq.htm

 

[Waldo Smets]

Thanks for the reply, Turtle, but I have no control over that.
IT people impose I MUST use unc paths. Tables were relinked (unc) on the
clients...

 

[Waldo Smets]

Kind of you, Joe, but I already checked out Tony's site.... Nothing there
that helped for this case...

Briefly: what can you do if Access is properly installed on client and
server and you can't get a client table to open at normal speed???

I do hope someone comes up with the magic suggestion!

 

[John]

Jerry, had the same situation. As long as the users were
in the same office as the server, the speed and connection
was fine (front end/back end). Once a user was outside
the office and had to use the VPN or at another office and
connected back to their office server, the speed was ...
well, let's just say it wasn't the speediest. I ended up
placing the app on the Citrix server, split it with both
front and back ends still in the folder on the Citrix and
now the users don't need Access or the front end on their
machines. Multi-user is available from the front end and
it also gave the user connectivity thru the internet from
anyplace they can get internet connection. The Citrix has
a www site to go to for accessing it. It was tried thru
high speed connections as well as regular dial up modems.
The modems weren't as fast as the high speed but it was
still acceptable. Still need to compact and repair every
so often.
Just letting you know what we did to resolve the speed,
connection, and usage issues for the employees that are
scattered around the country.
*** John

 

[Waldo Smets]

Thanks, John, but I simply have barely anything to say over IT policies...
can't go citrix (or anything else) just like that...

I'm given a couple of days to sort out the Access performance problem and if
it doesn't work out, the back-end must be asap migrated to SQL Server.. I
wouldn't have mind to put it SQL Server in the first place, but now that I
was asked to develop it Access FE/BE, I'm not so eager to migrate
(especially as there are related programs that need to be moved too, then)
.... While I just can't image you can't get an Access FE/BE running normally
on your average network.....

 

[Mike Matheny]

Hope you get an answer to this - I have a client with a small Access
database and a frontend/backend just like you specify, from XP clients to
W2K server, and it is slow as molasses!

 

[Albert D. Kallal]

Kind of you, Joe, but I already checked out Tony's site.... Nothing there
that helped for this case...

Briefly: what can you do if Access is properly installed on client and
server and you can't get a client table to open at normal speed???

I do hope someone comes up with the magic suggestion!

The answer is *usually* in Tony's article:

Did you actually try the suggestion to keep the connection open to the
back end? 9 out of 10 times this fixes the slow table opens. You can either
keep a table open when the front end starts up, or simply even open some
form to a table, and the minimize it. Now try the other forms and
operations. You should now find first rate performance. Are you saying that
you actually this fix as suggested in Tony's site? I have rarely seen this
fix not work.

Of course, the above trick even works when re-linking tables, but of course,
you pre-link the tables before you distribute the front end to the users on
the network anyway, so that is not really a problem.

You do everyone a big disservice here by simply browsing over such a fine
article that Tony has, and them simply coming back here for more
information.

If after trying the suggestions in Tony's article, then something else is
seriously wrong (I would consider to start firing the people involved in the
project, and hire some competent people who know what they are doing!).

 

[Albert D. Kallal]

Once a user was outside
the office and had to use the VPN or at another office and
connected back to their office server, the speed was ...
well, let's just say it wasn't the speediest.

Of course the speed would not be acceptable. But of course only a complete
fool would not ask what the speed of the VPN is compared to office lan. If
you paid any money to get that system set up for the VPN, then I would ask
for a immediate refund, as only VERY dishonest developers would suggest such
a setup (and if they were not dishonest, they simply were not competent).

You can read the following article of mine on using ms-access on a VPN:

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