New resource available:
Access 2000 to Access 2010 comparison
What professionals need to know to create, maintain, and evolve their useful Microsoft Access databases that start to take on a life of their own...
Thursday, March 25, 2010
Tuesday, March 2, 2010
Time for Spring Cleaning? Revisiting Your Access Database
It's fair to say few people I know involved with MS Access ever said to themselves, "I want to learn to be a database guru," or, "I want to specialize in Microsoft Access." If you are like most MS Access users, it fell upon you as you searched your Start Menu for what your company had installed on your PC. Or you bought Access thinking it might be useful some day. At the same time, your very first database may also be the most important one you use, the reason you started using Access, and the little application that makes your day go faster.
Unlike a Word document or a web page, the thought of doing a major rewrite of your database to run more smoothly can make you cringe. Your first few Access databases probably remind you of when you were learning volumes of new concepts while trying to put them into practice that same day. They are unwieldy and difficult to maintain. Fortunately, you are wiser now. You know that a single macro or line of VB can help you avoid creating 10 different copies of the same query just so they show information for 10 different products. You know that you can accomplish the same task with a few simple modular VB functions instead of the gnarly 200-line monster that your database relies on. Or you know now that you don't need three separate tables (Prospects, Proposals, and Customers) that all store essentially the same information, when a simple "Account Type" field can help you differentiate between them.
Whatever ugly solutions lurk in your database, as Spring rolls around and the economy starts to tick back up, it may be time to start eliminating the vestiges of your create-as-you-learn-the-basics work.
The Benefits
Before you set out to rewrite or rework part of your database, it's sensible to do a back of the napkin cost/benefit analysis. What will revising your Access database do for you?
So what can you do to clean up your database?
Unlike a Word document or a web page, the thought of doing a major rewrite of your database to run more smoothly can make you cringe. Your first few Access databases probably remind you of when you were learning volumes of new concepts while trying to put them into practice that same day. They are unwieldy and difficult to maintain. Fortunately, you are wiser now. You know that a single macro or line of VB can help you avoid creating 10 different copies of the same query just so they show information for 10 different products. You know that you can accomplish the same task with a few simple modular VB functions instead of the gnarly 200-line monster that your database relies on. Or you know now that you don't need three separate tables (Prospects, Proposals, and Customers) that all store essentially the same information, when a simple "Account Type" field can help you differentiate between them.
Whatever ugly solutions lurk in your database, as Spring rolls around and the economy starts to tick back up, it may be time to start eliminating the vestiges of your create-as-you-learn-the-basics work.
The Benefits
Before you set out to rewrite or rework part of your database, it's sensible to do a back of the napkin cost/benefit analysis. What will revising your Access database do for you?
- Less costly maintenance. Rewriting or reworking some of the most difficult-to-maintain areas of your database can save you time when you need to fix a bug or make a change needed to keep your business running. Instead of changing your code in 5 different places and making sure it all works, revising your database can mean you only have to make the change in one location, and test it once.
- Fewer bugs. If you simplify your Access database, and that is usually what you can do armed with greater knowledge of Access database design and development, you can reduce the number of failure points. And because your database accomplishes the same tasks with fewer steps, queries, macros, and/or lines of code, you can spend more time testing and adding error checks into those steps.
- Smaller database size. If you have your database on a shared network drive, then the size of your database will matter when users open it each time. Interestingly, deleting several redundant forms or optimizing your tables and indexes can make a big difference in the amount of space your database takes up. That in turn can mean faster loading times.
So what can you do to clean up your database?
- Revisit your indexes. If speed and size are important, make sure you have Access table indexes on the right fields. Access will often automatically add indexes to some numeric fields (especially if you created that table by importing from Excel), even if you don't often run queries against those fields. Conversely, you may find that Last Name or Email Address is very commonly used to search your database. You may want to add an index to that field to make your queries run faster.
- Use the Access "WhereCondition" argument for DoCmd.OpenReport and DoCmd.OpenForm (for macros, it is just Open Form and Open Report). In so many cases, I see people copying the same form, Access query, or report so that Report 1 is for Jane's sales numbers, and Report 2 is for Fernando's. The fields are all the same, everything is the same except for the sales rep. And each time you need to make a change to the report, you have to do it in 2 or more. Instead, use the WhereCondition argument to control whether the report should display Jane or Fernando's data.
- Compact, Repair, and Decompile. Compact and Repair are easily done. In Access 2000 and 2003, click on "Tools>>Database Tools..>>Compact and Repair." In Access 2007, select the Office icon, then Manage>>Compact and Repair. Decompling your Access database is something you should do if you find your application is behaving oddly, such as ignoring when you explicity set a variable, or crashing when you edit one of your Access forms. One of the Access MVPs has a fine page on the subject.
- Create lookup tables to improve consistency. If you have a field that should contain a finite number of values, but you find your users enter all sorts of junk, it may be time to create a lookup field and table. First, create the lookup table with the values you want to limit users to select. Second, you'll need to create a new lookup field in your main table. You can set the data type to "Lookup..." and Access will guide you through the process of pointing to your new lookup table. Last, you have to update existing records to set the new lookup field equal to the corresponding lookup key in the lookup table. To do that, create a new query that joins the lookup value (not the key, the value) in the lookup table to the "old" value field in your main table. Then, make the query an update query and say you want to set the main table's new lookup field equal to the lookup table's key field value.
- Simplify your code and macros. Whether you rely solely on macros, or you use VB heavily, simplification is always the goal. Try to break out our macros or VB into small pieces of single-purpose elements. If you have five macros that all update customer records, you may be able to create a single "master" macro that performs the update, and then all five simple point that that master macro to do the common work. Similarly, if you have the same VB code on each form that validates your required fields are populated, but that code is identical, become familiar with the "Me" form object reference and create a single VB function that sits in it's own module, and each form's code simply calls that main function and passes the "Me" object reference to say which form needs to be used when running the code.
Subscribe to:
Posts (Atom)