Even your least technical Access users can improve the performance of their databases. Susan Harkins shares some basic tips those users can put to work right away.
Performance matters, even in a locally stored single-user database. No one wants to waste time waiting for forms and reports to populate. You don’t build these slow databases, users do — but you might need to support them. Users build them and then they call you: My database is too slow! There are things you could do to help, but the good news is that you can offer a few tips that might help them improve performance on their own. All of the following tips are simple enough that most users can put them to good use with decent results.
Note: This article is also available as a PDF download.
Access displays subdatasheets between related tables by default. Unfortunately, they slow things down. If you work a lot in Datasheet view and seeing related data is valuable, it’s a great feature. Most of us, however, don’t need to see data presented this way. Advise users to disable this feature, as follows:
Access has two utilities that offer suggestions for improving performance. The Performance Analyzer lists potential problems and provides suggestions for correcting them. You can analyze all objects or just specific objects in a database. Another insightful utility is the Table Analyzer. This tool will help users properly normalize their data, and a properly normalized database performs better overall. These utilities are simple to run and users should be able to apply the resulting suggestions with little or no help from you.
In Access 2007/2010, both tools are on the Database Tools tab in the Analyze group. In Access 2003, choose Analyze from the Tools menu. These utilities will usually catch something — in a user-built database, they might find a lot. Advise users to run the Table Analyzer before building forms and reports, so they can build them on properly normalized tables.
Embedding graphics is a surefire way to consume resources and degrade performance. Linking is usually better than embedding, but users won’t always know how to link to graphic files outside the database. When this is the case, Access can reduce the bloat that comes with embedded graphics. Advise users to set the following option when they embed graphics:
In mdb versions (Access 2003 and earlier), Access stored two sets of each graphic, which significantly increased the size of the database — the original and a bitmap image Access actually displayed. The Preserve Source Image Format setting stores only one file and dynamically generates a bitmap when needed. The savings are substantial, but users won’t know about it. Advise users to set this option during the design/development process. It won’t convert existing graphics — it works only with new graphic files, as you embed them.
By default, Access stores your data and your user interface objects (forms, reports, and so on) together. Some developers claim that splitting these single files into two, one with the data and one with the user interface objects, improves performance. Users work in the front end, which contains the user interface objects that retrieve data, as needed, from a linked back end. There are a number of reasons to split a database, as you can read about in 10+ reasons to split an Access database, but managing the data and the database itself are greater incentives than performance. Users can sometimes improve performance by splitting a database (but that isn’t always the case).
If a database has only one user, you can still split it, but tell users to store both ends on the local system to avoid the network bottleneck. The idea might intimidate some of your users, but encourage them to try it — they’ll be surprised how easy it really is.
As stated in #4, splitting a database sometimes slows things down. When that happens, there are simple things that users can do to improve performance to a linked backend:
Compacting reclaims resources you free up by deleting objects and records. It also reorganizes records and updates statistics. Compacting almost always improves performance. If users don’t compact regularly, the change will be noticeable. Compact And Repair Database is in the Tools group on the Database Tools tab. In Access 2003, it’s on the Tools menu. Users can also have Access compact automatically, as follows:
In Access 2003, do the following:
Instruct users to set this option so the database will compact every time they close it. Be sure users know to back up their database before compacting.
Users might think that more is better, but a simple form is usually faster than a complex one with dozens of controls. A busy form can take a while to load and respond to requests. Advise users to create numerous task-specific forms instead of one complex form.
Users tend to save queries for forms and reports based on more than one table. Recommend that they base all bound forms and reports on a query instead. Then, they can use the query to limit the number of fields and records used to populate the form or report. The less data, the faster the form or report will perform.
Indexing isn’t an art, but it can be confusing — and over-indexing is as bad as inadequate indexing. Although there are many rules about indexing, they all boil down to one simple guideline that most users can understand: Apply an index to fields you sort or search regularly, unless the values are repetitive. If users are unsure, remind them to run the Performance Analyzer (#2).
The number of records stored in a table has less impact on performance than the number of fields in the table. Advise users to keep fields to a minimum. Normalizing goes a long way (and the Table Analyzer can help there). But sometimes, even a properly normalized table can have dozens of fields. If you suspect that a wide table is a performance problem, advise the user to remove seldom-used fields to a new table. Then, force a one-to-one relationship between the tables. If the number of fields is your true culprit, this arrangement should improve performance. Recommend this solution to only your most knowledgeable Access users, though. It isn’t difficult, but it does require knowledge of normalization and table design.
Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more. Delivered Mondays and Thursdays