Databases Reference
In-Depth Information
Precisely because Access cannot warn us about logical errors, they are the most
dangerous, because we
think
that everything is correct.
9.6 Debugging
Invariably, you will encounter errors in your code. Design-time and compile-time errors
are relatively easy to deal with because Access helps us out with error messages and by
indicating the offending code. Logical errors are much more difficult to detect and fix.
This is where debugging plays a major role. The Access IDE provides some very
powerful ways to find bugs.
Debugging can be quite involved, and we could include a whole chapter on the subject.
There are even special software applications designed to assist in complex debugging
tasks. However, for most purposes, a few simple techniques are sufficient. In particular,
Access makes it easy to
trace
through a program, executing one line at a time, watching
the effect of each line as it is executed.
Let us discuss some of the tools that Access provides for debugging code.
9.6.1 Tracing
The process of executing code one line at a time is referred to as
tracing
or
code stepping
.
Access provides three options related to tracing: stepping into, stepping over, and
stepping out of. The difference between these methods refers to handling calls to other
procedures.
To illustrate the difference, consider the code shown in Example 9-1. In
ProcedureA
, the
first line of code adds a new record to a recordset denoted by
rs
. The second line calls
ProcedureB
, and the third line updates the recordset.
ProcedureB
sets the value of the
LastName and FirstName fields for the current record. Don't worry about the exact
syntax of this code. The important thing to notice is that the second line of
ProcedureA
calls
ProcedureB
.
Example 9-1. Sample code for tracing methods
Sub ProcedureA( )
rs.AddNew ' Add a new record
Call ProcedureB
rs.Update ' Update recordset
End Sub
Sub ProcedureB( )
rs!LastName = "Smith"
rs!FirstName = "John"
End Sub
