Dan Waters
dwaters at usinternet.com
Mon Sep 25 10:55:58 CDT 2006
Here is what I have developed to trap and record errors: At the bottom of each procedure or function are these lines of code: Private Sub SubroutineName() On Error GoTo EH 'Code in Sub or Function Exit Sub EH: Application.Echo True Call GlobalErrors(txtProcessID, Err.Number, Err.Description, _ "Module Name", "Subroutine Name ", "ExtraInfo1", "ExtraInfo2") End Sub txtProcessID: This is usually the Primary Key for the record. Could be an empty string. Err.Number Err.Description Module Name: This is the name of the standard module the code is in. For a report or form I use Me.Name. Subroutine Name: This is the name of the subroutine. I have to type this in each time because there is apparently no system function to provide the name while the code is running. ExtraInfo1 & ExtraInfo2: This is an optional field that holds a variable or expression that will capture information that is unique to this procedure or function. This is particularly helpful when troubleshooting. The code above can use Select Case to handle different errors differently. The procedure GlobalErrors will record this information, along with Date, Time, PC Name, and UserName. GlobalErrors can give a message to users about a certain error (i.e., printer-related errors), and can prevent recording a certain error if I know it's irrelevant. Hope this was helpful . . . Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd- Think of it like this: If you don't at least trap the error in the procedure where it occurs, how do you expect to get that information? Errors that are unhandled in a procedure bounce back up until they find an error handler. By that time, you have no idea where they originated, you only know what the error is. So even if you have a "global" error handler, you still need to trap errors in the procedure so you know where to look for the problem. Charlotte Foust -----Original Message----- Subject: Re: [AccessD] Error Code Generator That was precisely my point. It seems the logical way to do it, but all the generators and the built-in stuff likes the local version. I don't get why that would be better. Given modern chip speed, it's obviously not about jumps. Maybe all the code does compress nicely but the local way seems so clumsy to me. ----- Original Message ---- Subject: Re: [AccessD] Error Code Generator I do it the way you just mentioned. I have a global errorhandler, that receives the information I want to 'monitor' from each procedure. It saves time and space, and with a central point for errorhandling, I can force things pretty easily. (Record the errors in a db, shut the system down, etc.) Drew -----Original Message----- Subject: Re: [AccessD] Error Code Generator I didn't write it, but it raises a question that I have wondered about for a while. Why is it better to embed the error routine in the particular proc or func than to write one global error handler and pass it the text and perhaps the proc/func name, so there's only one error handler in the whole app? I never did understand this. Can anyone provide some insight? Arthur ----- Original Message ---- Subject: [AccessD] Error Code Generator I believe someone on the list created an error generator. I believe it might be JC? Anyway I have been using it a lot for code examples and just to be politically correct want the owner to know. Example below Function CopytoWss() On Error GoTo Err_CopytoWss DoCmd.SelectObject acTable, "Contacts" DoCmd.RunCommand acCmdExportSharePointList Exit_CopytoWss: Exit Function Err_CopytoWss: MsgBox Err.Description, , "Error in Function CopytoWss" Resume Exit_CopytoWss Resume 0 '.FOR TROUBLESHOOTING End Function Martin