You can handle run-time errors that trigger an Error event by adding code to a form or report’s Error event procedure. The Error event is triggered by any run-time error that is generated either in the Microsoft Access interface or by the Microsoft Jet database engine. The Error event won’t trap errors in your Visual Basic code. To handle run-time errors generated by Visual Basic, use On Error statements.
See Also For information on the Error event, search the Help index for “Error event.” For information on handling Visual Basic run-time errors, see “Using On Error Statements” later in this chapter.
For example, the Orders form in the Orders sample application includes code in its Error event procedure to handle the error that is generated if Microsoft Access tries to save a record that doesn’t have an EmployeeID or CustomerID value. When Microsoft Access generates this error, the Form_Error procedure traps it and displays a custom dialog box.
Private Sub Form_Error(DataErr As Integer, Response As Integer)
' If error is due to a broken join (missing CustomerID), display a
' message telling the user what's missing and how to cancel the order.
Const conErrBrokenJoin = 3101
If DataErr = conErrBrokenJoin Then
MsgBox "Every order must have a customer for billing. " & _
"Select a company name in the Bill To list, or to " & _
"cancel the order, click Undo Current Field/Record " & _
"on the Edit menu.", vbExclamation
Forms!Orders.SetFocus
BillTo.SetFocus
Response = acDataErrContinue
End If
End Sub
When an error triggers an Error event in the Orders form, Microsoft Access runs the Form_Error procedure and passes the error code for the error to the procedure’s DataErr argument. For example, if you enter a new record, but neglect to enter a value in the Salesperson box (EmployeeID field), then try to move to the next record, Microsoft Access:
The procedure declares the constant conErrBrokenJoin, which represents error code 3101, for the broken join error.
The If statement then uses this constant to test whether the DataErr argument matches this error code. If it does, the procedure traps the error and displays a custom dialog box so the user can correct the problem by entering a value. It then sets the procedure’s Response argument to acDataErrContinue, which causes Microsoft Access to continue execution without displaying the standard Microsoft Access error message.
Important Because this error-handling code relies on the DataErr argument of the Error event procedure, you can do this kind of error trapping only in an event procedure. You can’t trap an error by specifying a macro as an OnError property setting for a form or report.
You can often use an Error event procedure in this way to display a custom message that is more meaningful to your application’s users than a standard Microsoft Access error message.
You can also add code to the Error event procedure to either take some action to correct the error, or to give the user an opportunity to correct it. For example, in a multiuser environment, an Error event procedure can handle common locking conflicts, such as those that occur when one user attempts to update data or save a record that is locked by another user. You can add error-handling code to the procedure to automatically retry an operation that has failed because of a locking conflict, or to display a custom dialog box that gives users the choice of retrying or canceling the operation.
See Also For information on handling errors in a multiuser environment, see Chapter 10, “Creating Multiuser Applications.”