Lavsa, Rich
Rich_Lavsa at pghcorning.com
Mon May 9 07:16:25 CDT 2005
3 ideas come to mind. 1.) Keep it simple and build a basic Text file log system that builds a new log file every night with Date and Time stamp. 2.) Keep a log Table within the same database that runs the reports 3.) Keep an external Database that gets written to with the errors. This method would be a nice way to keep your production database from potential bloating, but it could also act as a central place to log all your errors for all your systems. I like this idea because you can build things into this system that are totally outside the realm of your production systems. For instance you could send your self emails on how your Sales Database worked today, or how your Inventory database performed, given you have set it up to log certain key events or performance markers for each database. Anyway, just some ideas. With the above in mind, the idea at hand is to trap your error, write your error to one of the places above, then maybe use a GOTO statement or a RESUME statement to go back up to your code, depending on how you are opening/refreshing your reports and emailing/ftp'ing your information. Rich -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Friday, May 06, 2005 6:08 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Tracing program flow >you just have to be prepared that what can fail sooner or later will >fail. Exactly. The last system has been in place for a couple of years and all kinds of weird errors have popped up. In that case a message box opened, halting the program flow. The reports would not go out and I could remote in to see the errors. I want the process to continue so that if a specific report failed for whatever reason, the next one would go out (assuming no errors there), which means silent logging, notification of the errors, and sufficient information to trouble shoot the issue since I no longer have the program halted at the scene of the crime so to speak. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Friday, May 06, 2005 3:13 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Tracing program flow Hi John Not to shortcut your clever thoughts and comments here, but it sounds like you may expect a flood of errors. As you are capable of writing robust code popping no messageboxes, my guess is that the only errors you'll ever meet will be at the transmitting (mail, fax, ftp) process where - on the other hand - all sorts of errors can arise and - worse yet - you can't even set up a test scenario that simulates all these errors; you just have to be prepared that what can fail sooner or later will fail. /gustav >>> jwcolby at colbyconsulting.com 05/06 8:39 pm >>> I am designing a system to create reports to be sent to a client automatically every evening. I did this before and had consistent issues with error handling, msgboxes in error handlers popping up and stopping the process etc. This time there will be no msgboxes, but errors must be reported thus I am trying to build a system that can be called from the error handler or where a message box would pop up. The system will log all such messages. Some thoughts in no particular order. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com