Visual Basic for Applications (VBA) is the language used for writing subroutines (subs) and functions in Access. Once you get past some of the fundamentals of VBA and start writing subs and functions, you will find that you need to debug your code to insure that it is doing what you intended. To assist you in debugging your code, Microsoft has conveniently provided some excellent debugging tools. These tools are made available to you in the Debug Window. You open the Debug Window while in Code View of any sub or function by selecting the View menu bar option then selecting Debug Window, or by pressing Ctrl-G. The "Debug" menu item on the menu bar also has some other items of Debug assistance.
    Before you use the Debug Window, you need to make sure that some options are set in Access 97. Click on Tools, then Options, then Module. Check all Coding Options and Windows Settings to make sure they are all selected. The default colors and options will work best for you, at least while you are starting out.
    The Debug Window is really a tabbed form with two panes. The upper pane is the Watch Window and the lower pane is the Immediate Window. We will start with the Immediate Window.
    In the Immediate Window, you can assign values to variables and/or objects, and you can print data using VBA code. I find that I use the print method more than anything else in this window. There are several ways to print to the Immediate Window. For the first example, put a "Stop" statement in your code. When the code reaches the Stop statement, it will stop. At that point, you can enter a ? to indicate a Print statement in the Immediate Window. As an example, you can enter ? <Variable Name>. The value in the variable will be printed on the next line.

? forms!frm_spec!Day1

will print the value in the control named Day1 found on the form called frm_Spec. 

? 2 + 2

will print the sum of 2 plus 2. Try it.

    You can also test functions or subs from the Immediate Window by entering the following, for example:

? IsFormOpen("frm_main_menu")

The function that checks if the form is open will return a result of -1 if the form is open and 0 if the form is not open. Of course, the function must exist in a module in the program before you can call it. You do not need to use a Stop statement to test a function or sub. Simply open them in design view and then open the Immediate Window.
    If any function requires arguments, place them in correct order between the parentheses. To call a function, use:

? <function name> ( arg1, arg2 Y )

Always include parentheses when calling functions even if they don't have arguments. If you call a subroutine that requires arguments, place them after the sub's name without enclosing them in parentheses. Since subroutines do not return anything, you don't need the "?" in front of them. To call a sub, use:

<sub name> arg1, arg2 Y or Call <sub name> arg1, arg2 Y

In VBA code, you can use the Debug.Print statement to print almost anything to the Immediate Window. The syntax is the same as that for the "?" above except that you replace the "?" with "Debug.Print".

Debug.Print "Change is good. You go first."

Instead of using the Stop statement to halt execution, you could have set a breakpoint in your code. To set a breakpoint, highlight the line of code on which you want the execution to stop. Click the Breakpoint toolbar button or select the Debug option on the menu bar, then select Toggle Breakpoint. Setting the breakpoint will change the color of the line selected to dark red and it will also place a red dot to the left of the line selected.

    To reset the Breakpoint, do the same thing since it toggles to the opposite condition. To clear all Breakpoints in the program, select Clear All Breakpoints in the Debug drop-down menu while viewing code.
    Pressing Ctrl-Break will also stop program execution. After you have stopped program execution by any of the methods above, you can then step through the lines of code one line at a time. Access 97 gives us Step Into, Step Over, Step Out, and Run To Cursor as commands we can use for stepping in code. You will find these commands on the Menu Bar under Debug and on the Button Bar next to Set Breakpoint.
    Step Into steps through code one line at a time. To start stepping, press F8. 
    Step Over is similar to Step Into except that it does not go into functions or subs when you call them. Use this when you are calling other functions or subs that you have already debugged and don't need to enter one step at a time. Press Shift-F8 to Step Over.
    Step Out gets you out of really messed up problem areas or out of procedures that you went into accidentally. Press Ctrl-Shift-F8 to Step Out.
    To test a portion of a procedure, halt the execution as before. Then set your cursor at the end point in code of the portion you want to test. Press Ctrl-F8 and the program will Run To Cursor and stop again. When you have completed testing, press F5 and the program will resume normal execution.
    In any of the four stepping tools, while stopped, you can examine variables to see what is happening in your program. Stepping also will show you whether your program logic is correct by allowing you to see which lines of code are being executed. If it is branching because of the value in certain fields, you can see what the value is and therefore confirm that branching should or should not have happened.
    To see what the value of any variable is, put your mouse cursor on the variable in the line of code where it is mentioned. The value of that variable will appear next to the name of the variable. To see the value of several variables at once, use the Debug.Print method instead.
    The two tabs at the top of the Immediate Window are labeled "Locals" and "Watch". In the Locals tab, all variables in the current module are displayed and their values are also shown as soon as the value changes. A plus or minus sign at the left end of a variable indicates that it can be exploded or collapsed. Try it to see how exploding or collapsing does change what you see in the Locals tab.
    There is one thing to remember when you are writing VBA code in Access or Visual Basic regarding the use of error handling routines to trap and deal with errors. Do not use the your normal error handling methods until you have finished debugging your code and tested it thoroughly. If you use an error handler before you finish debugging, the routine will handle the error and you will not have a clue where it occurred unless your error handler is smart enough to trap and identify every error that could possibly occur.
    So always put your error handlers in as the last thing you do in development. I use and recommend Total Access Code Tools from FMS Inc. for the purpose of adding the error handling code. Total Access Code Tools is an excellent package.
    Just as an error handling routine will mask errors, some of the commercial software intended to make life easier for a computer user can make it more difficult for the database developer. For instance, Symantec's Norton Crash Guard will notify you if a fatal error has occurred and intercept it before your system crashes. The main purpose of Crash Guard is to protect the system from crashing, and it works really well. When Access is running, it will probably prevent your error handler routine from processing the error. It will, in almost all cases, mask the error and prevent you from knowing what is happening from a programming perspective. It should be un-installed or turned off while you are debugging your VBA code.
    This article just covers some fundamentals of debugging to get you started. Check the Access help files and newsgroups for more information. There is a lot more to learn.