[AccessD] No MsgBox allowed

Ken Ismert KIsmert at TexasSystems.com
Tue Sep 28 11:27:53 CDT 2004


John,

I faced a similar problem when setting up a datamart application which runs
nightly on the server. I needed error logging and notification when a
sub-process failed, but the rest of the processes needed to run, if
possible.

My response was to develop an error logging system with plug-ins to support
the various destinations of the logged messages. All the plug-ins support a
common interface, IErrorLog, which defines the common properties and methods
each must support.

So far, I have written plug-ins that will log errors to tables using ADO and
DAO, email via CDONTS and MAPI, text files, the console (immediate window)
and yes, the message box.

What plug-ins get used is defined by an .ini configuration file. For
production, errors are routed to tables, CDONTS email and text. For
development, another .ini file is used which routes errors to the console
and message box.

What the loggers do is defined in part by template text files. For the table
loggers, these contain SQL statements. For the email, text and console
loggers, these have boilerplate text. All template files contain tokens,
like <ErrNumber> and <ErrDescription>, which are replaced by the matching
information when the error is logged.

This is all managed by a global error handling object, which keeps an
internal record of all errors encountered during execution, and logs errors
with all the currently active loggers. It allows the error generating
routine to save the current error, or raise it. Calling routines can examine
the error results of a call, and skip dependant calls which follow, go on to
the next process, or raise the previous error.

-Ken


-----Original Message-----
From: Colby, John [mailto:JColby at dispec.com]
Sent: Monday, September 27, 2004 1:46 PM
To: 'AccessD at DatabaseAdvisors.com'
Subject: [AccessD] No MsgBox allowed


I am doing a rewrite on an app that runs unattended and emails (or FTPs)
files out to a client.  This app absolutely must run, or at least if it
fails it has to NOT pop up a message box and halt the process.

<snip>

Aside from the obvious "Access is not the optimum environment to write such
an app", has anyone done stuff like this (in Access) and do you have any
thoughts on the issues above or any others I haven't raised?

<snip>

John W. Colby
The DIS Database Guy






More information about the AccessD mailing list