By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,385 Members | 847 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,385 IT Pros & Developers. It's quick & easy.

Slow Database

P: n/a
I'm using Access2000.
I have just designed a database which seems to be operating very slow on a
network. There are currently only a few records in it.
Should I be compacting it now before it gets busy with usage ?
The database has OLE bounded fields where pictures are linked to a network
folder where the pictures are kept. Will this linking of pictures to
respective records over time hinder the speed of the database ?
Nov 13 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a

"IkyL234" <g4****@hotmail.com> wrote
I'm using Access2000... database...
seems to be operating very slow on a
network. ...currently ... few records in it.
Should I be compacting it now before
it gets busy with usage ? ...OLE bounded
fields where pictures are linked to a
network folder where the pictures are
kept. Will this linking of pictures to
respective records over time hinder
the speed of the database ?


There are many factors involved in performance of a networked split Access -
Jet database -- some are the hardware, software, and network environment and
the requirements, design, and implementation of the database application.
For an overview of Access in a multiuser environment, see my presentation on
the subject at http://appdevissues.tripod.com/downloads. For the best
detailed information and links on performance and avoiding corruption in the
multiuser environment, see MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm.

We don't have much to go on in your question... "seems to be operating very
slow on a network" just isn't very detailed nor precise.

My first suggestion: be certain sure you have every Service Pack, update,
and patch installed for Access 2000. (If it were mine, I'd be using either
Access 2002 or 2003, if I had the option, and would have every update
installed on those, as welll.)

My second suggestion: be sure you pay careful attention to the part about
splitting the database and giving each user their own copy of the front end
(queries, forms, reports, macros, modules, and local lookup tables, if any).

My third suggestion: be sure you keep an open connection from each front end
to the back end in which the tables reside.

My fourth suggestion: every Access database that exhibits a tendency to grow
should be regularly compacted... just how regularly, again, depends on a lot
of things -- weekly is common, daily is needful in some cases. You might
also take a look at things that could be causing extra "bloat" and see if
you can do those things some other way (for example, temporary tables should
be created in a temporary database and linked... once you are through with
the tables, unlink them and delete that entire database.)

Beyond that, I'd tell you to visit Tony's site, read carefully, and follow
the good advice. (The "golden age of Access multiuser" were the days of Win
98, Win NT 4.0, and Access 97 -- not because they were necessarily better,
but because the installation defaults were more attuned to multiuser. It is
still possible to get very good performance but it takes a bit more effort
and attention, now.)

Moving images (which tend to be large files) over a network, multiple times
for multiple users, is going to be a drag on performance even if you have
your application well-tuned. You might consider an approach other than bound
OLE Objects, so you'd have more control... see the Imaging examples at
http://accdevel.tripod.com for some alternatives.

Larry Linson
Microsoft Access MVP


Nov 13 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.