Microsoft Access 2010 Bible

Chapter 31: Distributing Access Applications

1099

can be caused by users, such as invalid data entry, attempting to run a function when the applica-

tion is not ready to run the function, and allowing users to click a Calculate button before all nec-

essary data has been entered. Bulletproofing your application is an additional stage that should be

completed in parallel with debugging, and should be performed again after the application is

working and debugged.

Cross-Reference
Chapter 26 discusses many bulletproofing techniques in addition to those discussed here.

Using error trapping on all Visual Basic procedures

An error-handling routine gives you a chance to display a friendly message to the user, rather than

some unintuitive default message box. Figure 31.9 shows a message box with a runtime error

“2102,” which is unintuitive; however, it also shows a more-detailed message of a form missing or

misspelled. The user won’t know the name of the form or if it’s misspelled or missing. An error-

handling routine is needed to provide the user with a more informative and meaningful error mes-

sage than what’s shown in Figure 31.9.

FIGURE 31.9

An error message resulting from a procedure with no error-handling routine

One of the most important elements of bulletproofing an application is making sure that the appli-

cation never crashes — that is, never ceases operation completely and unexpectedly. Although

Access provides built-in error processing for most data-entry errors (for example, characters

entered into a currency field), automatic processing doesn’t exist for VBA code errors. You should

include error-handling routines in every VBA procedure, as described in Chapter 23.

When running an application at runtime, any untrapped error encountered in your code causes

the program to terminate completely. Your users can’t recover from such a crash, and serious data

loss might occur. Your users have to restart the application after such an application error.

Separating tables from the rest of the application

You should separate your code objects (forms, reports, queries, modules, and macros) from your

table objects. Many benefits are gained from distributing these objects in separate .accdb files: