Access Extremely slow from Server.

[Mike]

Hi all,
Wasn't sure where in here to post this as it don't come
under existing Access Categories so here goes:
I have a few Access 2000 databases that live on a WinNT4
server that have become almost unbearable to use when
designing changes etc. Just to update a form field can
take up to 3 mins before being able to do anything. I have
monitored the server that these databases reside on and it
is always under 10% utilized and memory is not a prob.
These databases are not big Say 1.5MB with Approx 100
records and have been compacted etc. I have done File
transfer tests to and from the server and no problem there
either. I have virus checked the whole server (as the prob
only started approx 2 weeks ago) and no, nothing. I tested
by creating a new database in same directory with some
dummy records etc and it flys along.. I have also Opened
the databases from other machines to verify that it was
not happening as a result of something screwy on the local
PC and this made no difference still slow. When the
database is copied to local PC it goes along fast as
expected. Any suggestions would be greatly appreciated and
thanks in advance. PS there are no error messages.
Regards Mike.

 

[Tim Ferguson]

Wasn't sure where in here to post this as it don't come
under existing Access Categories so here goes:

It's fair enough not being sure, and in those circumstances it's even
reasonable to cross post to a number of groups.

But it's always an unpopular thing to multipost the same message once each
to a bunch of groups. The result of this is that replies to one don't get
echoed to the others, so more people waste time providing a reply that has
already been given; the other thing is that many proper newsreaders will
suppress repeats of crossposted messages but cannot detect multiposted
ones, so that we end up having to read the same stuff time after time. Like
this one.


Anyway, you need in the first place to look very carefully at the network
performance as a whole: access is very sensitive to dodgy NICs for example,
even on machines not directly involved in the path, and you may be at risk
of corrupting the file too. Second, make sure that nobody is sharing the
mdb at the same time -- Access shares data very well, but is not good at
multiusing UI objects like reports and forms particularly when they are
being edited at the same time. I suggest copying the front end to your
development machine and working locally (with test data, of course!) and
then distributing it back to the users' local machines for them to use on
their own.

HHT



Tim F

 

[Mike]

Thanks Tim,
And point taken.
Mike.

-----Original Message-----


It's fair enough not being sure, and in those circumstances it's even
reasonable to cross post to a number of groups.

But it's always an unpopular thing to multipost the same message once each
to a bunch of groups. The result of this is that replies to one don't get
echoed to the others, so more people waste time providing a reply that has
already been given; the other thing is that many proper newsreaders will
suppress repeats of crossposted messages but cannot detect multiposted
ones, so that we end up having to read the same stuff time after time. Like
this one.


Anyway, you need in the first place to look very carefully at the network
performance as a whole: access is very sensitive to dodgy NICs for example,
even on machines not directly involved in the path, and you may be at risk
of corrupting the file too. Second, make sure that nobody is sharing the
mdb at the same time -- Access shares data very well, but is not good at
multiusing UI objects like reports and forms particularly when they are
being edited at the same time. I suggest copying the front end to your
development machine and working locally (with test data, of course!) and
then distributing it back to the users' local machines for them to use on
their own.

HHT



Tim F

.