Part II: Programming Microsoft Access
524
Cross-Reference
Chapter 23 contains valuable information about adding error handling to your Access applications. You can’t
exclude every type of problem from your Access databases, but you can, at least, prepare for the inevitable
issues that arise in database applications.
Note
This chapter assumes that you’re comfortable designing and implementing the data structures in your applications
and that the tables, queries, and other structural components of your databases are not a source of problems.
On the CD-ROM
This chapter is a departure from the other example files you’ve used in the book. The sample database file
(Chapter14.accdb) contains the basic example code shown throughout this chapter. The code in
Chapter14.accdb does not necessarily do anything useful. It’s provided mostly as a “test bench” for prac-
ticing with the Access debugging tools rather than as a good example of practical VBA code.
Many of the statements in the examples have been commented out because they contain syntax errors and
other types of problems. You may have to remove the single quotes in front of some of the example statements
to experience the error or view the assistance already built into Microsoft Access.
Finally, there are many more examples in Chapter14.accdb than are described in the text of this chapter.
After you read the chapter, go back through the examples and try them out. You’ll learn more about debugging
than you probably ever wanted to know, but the experience will serve you well as you develop and debug your
programs.
Testing Your Applications
Testing Access applications is an ongoing process. Each time you switch a form or report from
Design view to Normal view, or leave the VBA Editor to run a bit of code, you’re testing your appli-
cation. Every time you write a line of code and move to another line, the VBA syntax parser checks
the code you just wrote. Each time you change a property in a form or report and move your cur-
sor to another property or another control, you’re testing the property you’ve changed.Testing is the time to see if your application runs the way you intend, or even if it runs at all.
When you run an application and it doesn’t work, you’ve found a bug. Fixing problems is most
often referred to as debugging. This term dates back to the earliest electro-mechanical computers.
Legend has it that a moth shorted out an electrical circuit. The late Admiral Grace Hopper, an early
pioneer in computing, coined the term debugging to describe the process of removing the moth.You’ve already learned a lot about testing and debugging. When you run a report and no data
appears, you’ve had to check the report’s RecordSource property to ensure that the report is
pulling the correct data. You may have viewed the data in a query or table to see if the data source
is the problem. If you run a form and you see #Name or #Error in individual controls, you’ve
learned to check the control’s ControlSource property. Perhaps you have an incorrect reference
to a table field or you spelled something wrong and Access is unable to evaluate the reference.