By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,136 Members | 1,054 Online
Bytes IT Community
Submit an Article
Got Smarts?
Share your bits of IT knowledge by writing an article on Bytes.

Custom Error Messages

ADezii
Expert 5K+
P: 8,638
One of the most frequently asked questions here at TheScripts is: Can I replace Standard Access Error Messages with my own? The answer is yes under certain circumstances and it involves the placement of code in a Form's Error() Event and setting a specific Parameter to either 1 of 2 values. Many Errors occur while your Form is active and it is within this context that you can replace the standard Access behavior when these Errors occur with behavior that is a little friendlier to the User. As previously stated, by attaching code to the Error() Event of a Form, your Procedure will be called whenever a Trappable Error occurs while the Form is running.

The Syntax for the call is as follows:
Sub Form_Error(DataErr As Integer, Response As Integer)
__1. DataErr - contains the Error Number for the Error that just occurred.
__2. Response - Allows you to specify how you want Access to handle the Error. If your code handles the Error to your satisfaction and you don't want Access to intervene or display its own message, place the value acDataErrContinue in Response. If you want Acces to display its own Error Message, place acDataErrDisplay in Response.

The following code traps 4 Errors that might pop up. In each case, the procedure replaces the Standard Access Error Message with its own. If an Error occurs that it hadn't planned on, the Procedure just passes the responsibility back to Access:
Expand|Select|Wrap|Line Numbers
  1. Private Sub Form_Error(DataErr As Integer, Response As Integer)
  2. Const conErrDataValidation = 3317
  3. Const conErrDataType = 2113
  4. Const conErrDuplicateKey = 3022
  5. Const conErrNullKey = 3058
  6.  
  7. Select Case DataErr
  8.    Case conErrDataValidation, conErrDataType
  9.       'your Error Message here
  10.       Response = acDataErrContinue  
  11.    Case conErrDuplicateKey
  12.       'your Error Message here
  13.       Response = acDataErrContinue   
  14.    Case conErrNullKey
  15.       'your Error Message here
  16.       Response = acDataErrContinue   
  17.    Case Else
  18.       ' It's an unexpected error.  Let Access handle it.
  19.        Response = acDataErrDisplay
  20. End Select
  21. End Sub 
Mar 24 '07 #1
Share this Article
Share on Google+
7 Comments


Denburt
Expert 100+
P: 1,356
Sweeeet!!! Thanks I should have implemented somthing along these lines YEARS ago....Will do so immediately, upon returning to work of course.
Mar 25 '07 #2

NeoPa
Expert Mod 15k+
P: 31,494
Sweeeet!!! Thanks I should have implemented somthing along these lines YEARS ago....Will do so immediately, upon returning to work of course.
Echo!
Nice one ADezii.
Mar 27 '07 #3

ADezii
Expert 5K+
P: 8,638
Echo!
Nice one ADezii.
Thanks, NeoPa.
Mar 28 '07 #4

P: 17
I'll take that error code suggestion one step further.

Using your code still only gives the user a small obscure message that is not nicely formatted. In many cases all they need is this but, there are some cases when a more detailed explanation is needed.

In this case, I propose a table of error codes and explanations.

Thus using your code or a variation thereof.....you could OnERR open a POPUP
form and have it access a record in the Error Code Table.

Then in creating that table use your error code numbers as one field and the explanations as the next field.

The POPUP form would only show the second field, nicely formatted.
Example: Error 2003

You have hit the enter key.
You need to hit the Tab Key.
When at first you don't suceed.
Try Try Again.

Then below this place a button that closes the form labeled
TRY AGAIN

This error message not only tells them what they did wrong,
It tells them how to fix it!
May 4 '07 #5

NeoPa
Expert Mod 15k+
P: 31,494
I did something similar once with an error table (I still use). I included the type of continue allowed (You can retry with an ODBC timeout type error for instance). The problem I found was that you never get told when Microsoft change the error list.
May 4 '07 #6

ADezii
Expert 5K+
P: 8,638
I did something similar once with an error table (I still use). I included the type of continue allowed (You can retry with an ODBC timeout type error for instance). The problem I found was that you never get told when Microsoft change the error list.
Good point, Neo. It's not like they're Intrinsic Constants.
May 4 '07 #7

hyperpau
Expert 100+
P: 184
Hi,
I would like to contribute to this. :)
Information courtesy of FishVal.

http://bytes.com/forum/thread830828-custom+error+messages.html
Aug 18 '08 #8