Suppress debugging or runtime errors prompts.

[raziel3]

My database works 99.99% of the time. Once in a blue moon I get an error and this is usually rectified when the user restarts the database. Most of the time I'm not there to see what caused the error.

Is there a way to suppress the error, log it in a table with the form name, error code and/or the module that threw the error and the only prompt the user gets is to restart the database?

 

[MajP]

Once in a blue moon I get an error and this is usually rectified when the user restarts the database.

I am assuming that is an unhandled runtime error. If it is locking up on a handled error then not sure there is a solution.

But if you want to log errors there are plenty of examples out there of creating an error log and writing to a file or table. Is that what you are asking?

Microsoft Access tips: Error Handling in Access Basic

How to trap and log the errors reported while a Microsoft Access database is in use. (Access 1 and 2.)

allenbrowne.com

Also this will likely require you to write a lot of error handlers for most methods. If you use MZTools or something similar this will make doing that far easier, because you can add the handlers after the fact and build your own template to have it call the log.

 

[GPGeorge]

My database works 99.99% of the time. Once in a blue moon I get an error and this is usually rectified when the user restarts the database. Most of the time I'm not there to see what caused the error.

Is there a way to suppress the error, log it in a table with the form name, error code and/or the module that threw the error and the only prompt the user gets is to restart the database?

Northwind Developers Edition includes error handling and error logging, as MajP suggests. Feel free to incorporate it into your own application.

There is at least one commercial product, called VBWatchDog, which can be used to implement error handling and logging.

 

[The_Doc_Man]

Is there a way to suppress the error, log it in a table with the form name, error code and/or the module that threw the error and the only prompt the user gets is to restart the database?

You have gotten affirmative responses from two very capable members. Rather than just repeat what they said, I'll add this: The use of an error handling routine can probably suppress all of the error messages and let you substitute a message of your choice. The part that is a bit tedious is to include info about the faulting module.

Every time you call a subroutine or function, and every time an event routine is triggered, to have complete identification of every place that COULD fault, you would need to add one error handler per place that can "raise" the error. In other words, lots of tiny error handlers, one per function or subroutine or event routine.

The GOOD news is that you COULD make the error handling routine the same for each handler and just provide a string constant to identify the faulting location. I had a subroutine I used for that purpose that built an error record in a table and tagged that error with a time stamp, a location code, and the error number, plus the first 255 characters of the error message. Sounds wasteful, but if you have 99.99% of the code working, that table won't fill up very quickly because it won't be logging very much or very often.

 

[Galaxiom]

It is often assumed that every sub or function needs an error handler but this is not the case.

Upon encountering an error Access will work its way back up the calling stack until it reaches an error handler. Only when this process is exhausted, will it throw and unhandled error. If the code is being called from many different places it may be better to know where it was called from rather than the specific function that raised the error.

With functions that are being run from queries, it is often better for the error handler to cause the function return an out of scope value when it hits an error. For example, if the function normally returns a positive integer, have the error handler return -1 for an error. For functions that return strings just return the word Error or an informative description.

Otherwise the error handler will report, then the query will keep calling the function for the next row and so on until you kill the query.

 

[The_Doc_Man]

It is often assumed that every sub or function needs an error handler but this is not the case.

G. is not technically wrong, but if the issue is complete ability to identify a faulting module from a VBA context, you would need a high level of error handler inclusion. G's description - that the error works its way back up the stack until it finds an error handler - IS ABSOLUTELY TRUE - but if you are several layers deep when the fault occurs and more than one or two layers have to be discarded (the technical term is "unwound from the stack"), tracing back the error might be difficult. My answer is a "debugging" answer whereas his is more correct for production operations.

As a further note, if the routine has the ability to return a value (either as a function or through a parameter declared by reference to return a status) then the error handler can do both. It can log the error and make the routine return a specific out-of-bounds error value.

G.'s point about a query appearing to take a per-error loop is not wrong either. Which is why if a public user-defined function is called by a query, you might need to be a bit more careful with the error-logging part of function.