Part IV: Professional Database Development
1092
Tip
The Name AutoCorrect option is turned on by default in Access applications. Unless you find this option useful
in your projects, you should consider turning it off, as it has been in the Chapter31.accdb example accom-
panying this chapter.
Testing the Application before Distribution
After you finish adding features and have everything in place within your application, you should
take some time to thoroughly test the application. Testing may seem obvious, but this step is over-
looked by many developers, evidenced by the amount of buggy software appearing on the shelves
of your local computer store. If you don’t believe this to be true, check out the software support
forums on the Internet — almost every major commercial software application has some patch
available or known bugs that need to be addressed.Distributing an application that is 100 percent bug-free is almost impossible. The nature of the
software development beast is that, if you write a program, someone can — and will — find an
unanticipated way to break it. Certain individuals seem to have a black cloud above their heads
and can break an application (in other words, hit a critical bug) within minutes of using it. If you
know of such people, hire them! They can be great assets when you’re testing an application.While working through the debugging process of an application, categorize your bugs into one of
three categories:l Category 1: Catastrophic bugs: These bugs are absolutely unacceptable — for example,
numbers in an accounting application that don’t add up the way they should or a routine
that consistently causes the application to terminate unexpectedly. If you ship an applica-
tion with known Category 1 bugs, prepare for a lynching party organized by your users!
l Category 2: Major bugs that have a workaround: Category 2 bugs are fairly major bugs,
but they don’t stop users from performing their tasks because some workaround exists in
the application. For example, a button that doesn’t call a procedure correctly is a bug. If
the button is the only way to run the procedure, this bug is a Category 1 bug. But if a cor-
responding ribbon command calls the procedure correctly, the bug is a Category 2 bug.
Shipping an application with a Category 2 bug is sometimes necessary. Although shipping
a bug is officially a no-no, deadlines sometimes dictate that exceptions need to be made.
Category 2 bugs will annoy users, but they shouldn’t send them into fits.Tip
If you ship an application with known Category 2 bugs, document them! Some developers have a don’t-say-
anything-and-act-surprised attitude regarding Category 2 bugs. This attitude can frustrate users and waste their
time by forcing them to discover not only the problem, but also the solution. For example, if you were to ship
an application with the Category 2 bug just described, you should include a statement in your application’s
README file that reads something like this: “The button on the XYZ form does not correctly call feature such-
and-such. Please use the corresponding command such-and-such found on the ribbon. A patch will be made
available as soon as possible.”