Microsoft Access 2010 Bible

523

CHAPTER

Debugging Your

Access Applications

IN THIS CHAPTER

Verifying an application’s

features

Identifying where errors come

from and how to avoid them

Setting up code module

options

Getting help with your VBA

code

Debugging the traditional way,

with MsgBox and Debug.

Print

Taking advantage of the

debugging tools available in

Access

M

any Access applications rely on significant amounts of VBA (Visual
Basic for Applications) code in forms and reports, and as stand-
alone modules. Because of its power and flexibility, VBA is used
for all aspects of application development, from communicating with the
user to massaging and transforming data on its way from tables and queries
to forms and reports.

Because VBA code is often complicated (or at least, seems complicated!)
debugging an error or problem in an application can be difficult and time-
consuming. Depending on how well organized the code is, and whether sim-
ple conventions, such as providing descriptive names for variables and
procedures, were followed, tracking down even a small coding bug can be a
frustrating experience.

Fortunately, Access provides a full complement of debugging tools to make
your life easier. These tools not only save time by helping you pinpoint
where a coding error occurs, but can help you better understand how the
code is organized and how execution passes from procedure to procedure.

Note
This chapter largely ignores the errors caused by poor design — misrepresen-
tation of data caused by ill-designed queries, update and insert anomalies
caused by inappropriate application of referential integrity rules, and so on.
For the most part, these problems occur because of issues such as failing to
conform to proper design disciplines, misunderstanding Access query design,
and so on. What I can help you with, however, are the bugs that creep into
your VBA code, particularly those bugs that cause noticeable problems with
the data or user interface in your applications.