Access Slow Over Network

[Powlaz]

I am having some trouble accounting for slow performance of an Access based
application on a small network and could use some direction. Here are the
nuts and bolts:

1. There are 5 amply equipped Windows XP HOME SP2 fully updated, virus &
spyware free computers in a Workgroup in this company.
2. The Access database resides on a Buffalo Link Station network HDD.
3. A shortcut to the database is placed on everyone's PC
4. The owner of the company has talked to the Access application developer
about separating the front end so it can be installed locally but . . .
5. There are no uneeded protocols configured on the network card
6. It is a 100Mbps network
7. I applied a registry edit to stop each computer from checking the other
computers on the network for scheduled tasks.
8. Anti-virus has been configured to exclude the entire directory that the
Access database resides in.
9. Windows Firewall is on (but I don't know if that matters. When turned
off "things" didn't get better)

I'm not sure what else to write. What I know is the owner of the company
wants to throw some money at the problem and install a server that this
application will then reside on. Problem is I don't think the server will
make enough of a difference.

What things can I be looking at. I am stuck working with the database as it
is (not split). I don't know if maintenance is needed on an Access database
and I don't know if it's run. What I do know is that the application runs
very well when installed locally.

Are there adjustments that can be made to XP or Access or the network that
will allow the program to run faster? PLEASE point me in the right
direction. If I spend the money on the server and wind up with the same
results I'm going to be in bad shape.

OH - I almost forgot. How does one benchmark the performance of an Access
database? The owner of this company is looking for a 50% improvement in
current load times. How do I log the system's current performance so it can
then be compared to its performance after I've applied your suggestions.
Whew, Glad I remembered that one.

Thanks,

Po

 

[John W. Vinson]

Are there adjustments that can be made to XP or Access or the network that
will allow the program to run faster? PLEASE point me in the right
direction.

Start with Tony Toews' Performance FAQ:

http://www.granite.ab.ca/access/performancefaq.htm

The persistant table connection can make a huge difference. Proper indexing of
tables and queries is another major benefit.

 

[Albert D. Kallal]

4. The owner of the company has talked to the Access application
developer
about separating the front end so it can be installed locally but . . .

what do you mean "but...."

Your your company seems willing to
be spending some time on fixing performance problems, but not fix how you
do things???? I will bet for the last fifteen plus years you've always
installed software on each
computer WorkStation. Somehow, now you're suggesting to throw out all of
this time honored approach, and for some reason you not willing to install
the software on each WorkStation like you've done for years and years with
virtually every other application that you have.

The old story about leaving a horse to water comes to mind here.
I guess the problem here is that you're trying to come here and look for
some good solid advice, yet at the same time ignore good solid advice?

Read my following
article and splitting, as it not only tells you to split your database, but
explains why. It is the ***why*** you split apart is that you need to grasp
here.

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

The above explains the difference between applications that you create, and
the concept of a simple data file that an application consumes.

I should point out that *often* in many cases splitting does not help, nor
does it solves your performance problems. However it most certainly affects
the reliability of your operations in a significant way. It simply a good
practice to adopt. I guess it kind of problems beget problems, and the
solution here is the overall approach that you take goes a long way to
solve the many challenges that the IT industry will present to you.


Anyway, the definitive list of things "setup" wise for performance is
outlined here

http://www.granite.ab.ca/access/performancefaq.htm

Go through the above list of suggestions carefully, and then go through it
again.

If after going through the above list your performance problems remain, then
it is likely the design of the application that is causing the poor
performance, and not your particular network setup. is also possible that
your application simply is too large and complex and has too much data for
your given setup. for example does the application done well with two users,
but act you increase the workload to four users that's 100% increase, does
the application significantly slow down?

Software is very much a like a construction project, and if you don't get
the foundations of the building correct, then the rest the software you
build around it often will cause poor performance. It goes without saying
that good performing applications are the results of good solid designs,
and throwing more hardware at these applications usually does not fix
the performance issues at hand.

So, check out that performance list, as there is a significant number of
settings and things that can significantly changed how the application
performs.

 

[Dale Fye]

I'm with Albert, you gotta split the database.

The wording of your question makes it sound like your application is sitting
on a WAN, not a LAN. Is that the case? Is the server your application is
sitting on in the same vicinity as your users, or in another city?

You might also want to consider moving your data to a SQL Server (the
Express version is free and will allow up to 4 GB in a single database)
backend while maintaining an Access frontend. This can significantly improve
performance but obviously requires a split configuration.

--
Don''t forget to rate the post if it was helpful!

email address is invalid
Please reply to newsgroup only.

 

[Tony Toews [MVP]]

Start with Tony Toews' Performance FAQ:
http://www.granite.ab.ca/access/performancefaq.htm
The persistant table connection can make a huge difference.

That mostly only makes a difference if the app has been split into a
FE/BE. Which the poster stated hasn't happened yet.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Tony Toews [MVP]]

You might also want to consider moving your data to a SQL Server (the
Express version is free and will allow up to 4 GB in a single database)
backend while maintaining an Access frontend. This can significantly improve
performance but obviously requires a split configuration.

I feel that this would be overkill in this situation. While it would
likely solve the performance problem there is something else going on
that is the major problem. And obviously this is more work to setup
and maintain.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Tony Toews [MVP]]

2. The Access database resides on a Buffalo Link Station network HDD.

I'm thinking this device might be the problem. What happens to
performance when you move the database to one of the Windows XP
computers?

4. The owner of the company has talked to the Access application developer
about separating the front end so it can be installed locally but . . .

Strongly recommended.

OH - I almost forgot. How does one benchmark the performance of an Access
database? The owner of this company is looking for a 50% improvement in
current load times. How do I log the system's current performance so it can
then be compared to its performance after I've applied your suggestions.

Pick a slow report. Reboot the PC. Run the report. Time it.
Reboot the PC, trying something else and retime it.

Note that Access/Jet will cache data when running the same report
twice in a row without exiting the MDB. Now does this happen when
closing and restarting Access? Possible but I haven't done any
testing on this.

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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Visitbazaar Info]

Internet - Take Advantage of Multiple Windows When Surfing

SUMMARY: Stop jumping back and forth between index pages by using several
browser windows.

Why use one web browser window when you can have multiple? If you have an
adequate amount of memory, open up several web browsers to maximize your
surfing experience. One great way to do this is via a start page. Now,
instead of left-clicking on links or entries to view other pages,
right-click the links. From the pop-up menu that appears, look for something
like "Open in New Window" or "Browse in New Window."

MyNextWindow.com is a browser application which gives the experience of
multi window surfing simultaneously, and also increases the internet
browsing speed by applying various compression techniques and protocol
optimization. Reduces the upload and download time in FTP.

http://www.mynextwindow.com/

Regards
MyNextWindow.com