Error-
By Dana Jones
Errors
are inevitable. Users, almost by their nature, will not use your database exactly as you intended it to be usedare going to
do something to or with your database that is not as intended or foreseen.
Some errors you cannot prevent or even anticipate. Those will be the source
of much of your fire--fighting as a developer.
You
can, however, anticipate a
great many errors, and can write error-handling
code to deal with those errors so that the user never sees them. Anticipating
and writing work--around code for a specific error is
called "trapping" the error. For those errors you can't trap, you
can at least have Access return the error code and description, so that when
the user calls you in a panic, you at least have something more substantial
to go on than the usual: "It crashed."
Whenever an error is generated, the form or report recognizes the Error event. You can write code for the form's or report's On Error event property to address such a situation. The template for the event procedure is:
Private Sub Form(or Report)_Error(DataErr As Integer, Response As Integer)
Typically, Access automatically passes the error's assigned code as the DataErr argument. You use the Response argument to instruct Access on how to handle the error: either acDataErrContinue to suppress the default error message or acDataErrDisplay to display it. Unless you write code to the contrary, Access will display the default error message for each error that is generated.
The first step in error-trapping is to determine what error code is generated for each error you anticipate. These might be such things as error code 2237 for an unrecognised value entered in a combo box whose LimitToList property is set to True, or error code 3058 for a missing primary key value. The easiest way to do this is to use the MsgBox function and have it return the error code and description when an error occurs.
Private Sub Form_Error(DataErr As Integer, Response As Integer)
MsgBox "The error number is " & Err.Number & " and its description is " & Err.Description
End Sub
Once
you know what type of error is being generated, you can write error- trapping
code to change Access' default behavior. The easiest best way to do this
is to use a Case structure, such as the one below:
Private Sub Form_Error(DataErr As Integer, Response As Integer)
Select Case DataErr
Case 1111
Statements to handle error 1111 here
Response = acDataErrContinue 'Setting
the response argument thusly suppresses Access' default error-handling
Case 2222
Statements to handle error 2222 here
Response =
acDataErrContinue
Case Else
MsgBox "Your actions have caused error number " & DataErr & ". Please contact your data administrator."
Response =
acDataErrContinue
End Case
End Sub
Error-handling
is often an evolving art, as you become
awareare informed
of new and inspired ways your customers users have discovered
for generating errors. Wise use of error-handling procedures can help makde
your databases a little bit more user-proof.
Mike Gunderloy©2001
May be distributed as long as the copyright remains.