List of Error codes with Response codes

I'm working on a generic error handler. I've reviewed the other questions (and solutions!) regarding this process, but haven't found one that addresses the following nuance.

I understand that Access 2007 error codes have not only a numeric identifier and a description, but also have a code identifying the type or category of the error, i.e. a reference to the type of response Access should provide when it encounters the error. For example, some errors are application or object defined errors ("conAppObjectError").

I've found plenty of support to generate a table of all the error codes with their description, but none of the sample snippets of code I've found include the ability to include this "Response" code in the output. Knowing how Access will respond to any given error code, or to at least have an idea how serious Access determines the error to be, will be helpful for my routine.

Can any of you fine folks out there help me with this? As always, I am very grateful to you all for your willingness to assist!

John
jofoco4Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"but also have a code identifying the type or category of the error, "

What do you see that - category .... not sure what you are referring to ?

There is the AccessError() function, which gives the Description, although it's not always helpful.

Have you looked at the full Err object ? (see images).  That various properties and methods are defined in the VBA help file.

You want to be aware of this:

http://www.everythingaccess.com/vbwatchdog.htm

It's the most state of the art error handler anywhere, way beyond cool.  Check out my testimonial.

Here is another excellent resource on the subject:

http://www.fmsinc.com/MicrosoftAccess/Errors/ErrorNumber_Description.html





Capture1.gif
Capture2.gif
0
jofoco4Author Commented:
Thanks for these thoughts, MX. Perhaps I'm trying to draw too fine a point on this. That said, it's my (unstudied) sense that errors fall into (at least) two categories. For the purposes of this exercise, let's describe those two categories as "topical" and "fatal".

I guess I view it as being similar to the proposition that there are some errors with which one can use "On Error Resume Next" with impunity, and then there are other errors with which that practice would be ill advised.

I'm sorry I can't be more descriptive, and it's entirely possible that either my perception is all wet, or Access doesn't publish this information in any retrievable manner.

I'll pursue a couple of your suggestions and will log back in before the beginning of the work week.

Thanks again for your perspective. I value your time.

John

0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
I don't think Access really distinguishes between errors.  Any 'unexpected' error is potentially fatal, ie an error that you have not specifically trapped for and then display a corresponding message to the user as how to resolve.
On Error Resume Next is potentially dangerous ... unless you have a specific reason for doing it, because it can easily result in silent errors wherein something fails, and you never see the error message, yet wonder "Why isn't this working"

However, here is an example of where you would ... use On Error Resume Next:

On Error Resume Next
  ' execute some action here
If Err.Number = 0 or Err.Number = <SomeErrorYouExpectAndIsOkToIgnore> Then
    ' no action required  Error 0 means No error occurred.
Else
   Msgbox "Unexpected error: " & Err.Number & "  " & Err.Description
End If

' continue .....

I guess in a way, there are some non fatal errors which fall into the category of ANNOYING ... for example - Error 2501 - which if you don't use the code below, the user sees an annoying message..


You have button which opens a report ..
   DoCmd.OpenReport "YourReport"

But ... the report has No Data ... and in the OnOpen event of the report, you have a message box that pops up and says "Sorry, no Data"  if the NoData property = True ... and then you Cancel the opening of the report. Back at the Open command ... you will the get the message ""You cancelled the previous operaton".

So in this example ... you have to trap that error around the OpenReport command.

So ... maybe this example will help you track it down?
************************************
Private Sub cmdPrintApp_Click()
    On Error GoTo Err_cmdPrintApp_Click
    DoCmd.OpenReport "SomeReportName", acPreview

Exit_cmdPrintApp_Click:
    Exit Sub
Err_cmdPrintApp_Click:
    If Err.Number = 2501 then   ' You cancelled .....
         ' no action required
    Else
         MsgBox Err.Description
    End If
    Err.Clear
    Goto Exit_cmdPrintApp_Click
End Sub

I don't recall ever seeing any categorization of errors however, per se.

mx


0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jofoco4Author Commented:
Right. You address the distinction I sense. Trapping for the 'No Data' error was one of the first circumstances in which I realized that there are errors .... and then there are errors.

And I do understand. Ultimately, it's up to us out here in the trenches to figure out, on an error by error basis, what can and what cannot be done in any individual case. I guess I was thinking there might have been a path to simplifying that "what to do, what to do..." process with the assistance of a few DefCon levels as error code attributes. Alas.

Thanks again, MX. Quite characteristically, a very articulate response.

Now if you'll excuse me, I see another windmill atop that hill over there, and Sancho Panza is readying my armor.

Best,

John.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.