In this case, the Case action solicits a company name for the user using an Input Box. The Select Case uses DataErr to determine what happens when the form generates error 3314. MsgBox "The form error, " & DataErr & " has occurred.", _ "Please enter the company name for this new customer:", _ 'Solicit Company Name if user fails to enter one. Listing A Private Sub Form_Error(DataErr As Integer, Response As Integer) Once you know the expected error number, you can use a Select Case statement, or some other method, similar to the one in Listing A, to determine what happens when that specific error occurs. Access will also display its internal message (see Figure A) after you clear the message box. During the develop and testing stages, you can use a MsgBox statement to learn error numbers, as follows: Private Sub Form_Error(DataErr As Integer, Response As Integer) MsgBox DataErr End Sub Figure B shows the result of this event for our examples error, number 3314. The easiest way to determine a Form error's number is to display DataErr's value. Instead, determine the error or errors you want to control and let Access take care of the rest.
#MS ACCESS RUNTIME ERROR 94 CODE#
Where object is the name of the Form or Report object, DataErr is the error code that identifies the current action error, and Response determines whether the event displays an error message. The Error event uses the following syntax: Private Sub object_Error(DataErr As Integer, Response As Integer) End Sub Generally, you'll use it to redirect the flow, changing what happens after the Error event occurs. So you probably won't use this event to change the message. In this case, the default message is sufficient. Figure A shows how Access handles this error in a simple form based on the Customers table in Northwind (the sample database that comes with Access). But if you prefer, you can take charge of the event and force it to do the following:Ī common form error occurs when you try to save a new record without filling in all required fields (required at the table level). When this happens, Access displays a predefined warning message that's usually adequate. When that's the case, take matters into your own hands by usurping the object's Error event.īoth forms and reports sometimes generate action errors, such as trying to delete a record protected by referential integrity or trying to add a new record without filling in required fields. On occasion, you might find you want a little more control. By default, Access handles action errors without any help from you. If a form or report encounters an error, you'll find the information you need in an event - the object's Error event to be exact. When capturing and handling errors, you probably think of the Err object, which stores information about the current run-time error.
#MS ACCESS RUNTIME ERROR 94 PDF#
This information is also available as a PDF download.