Suppress debugging or runtime errors prompts.

raziel3

Registered User.
Local time
Today, 04:44
Joined
Oct 5, 2017
Messages
316
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?
 
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?
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.
 
Last edited:
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.
 
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.
 

Users who are viewing this thread

Back
Top Bottom