[AccessD] Log files

I thought you guys might appreciate seeing how I do this.  
 
I need to log things to text files all of the time for exporting data out to
clients.  I am writing processes (classes) where I export data to fixed
width files.  The export process is table driven and allows taking a
specification from the client that says what fields are expected, how long
each field is, how they are padded (left / right), with what characters
(space, zeros etc), date formats and so forth.  That export process (class
system) performs an export using a query that I build to get the data ready
for export.  The end result of that class system is a sequence of text
strings that are the export data.  Now a common task is that these export
systems need to write the data out to disk.  Another common task is that the
export process needs to log any errors that it encounters.
 
Given that this is a repetitive task I decided to create a class that my
export process classes could instantiate and then use.  It uses the Windows
File System Object, so if you work under a notwork Nazi who has locked down
your systems, you can pretty much stop reading now, or... you might want to
replicate this using the methods for file manipulations built in to Access.
I like the FSO and use it where possible.
 
This log class is designed to be instantiated, then left open to write (or
read)  to a text file.  In the Init() I pass in the pieces of the file name,
the path, the file name, the extension.  I like to date / time stamp my
files in the file name so that I can write the same type of file out to a
common directory and be able to see right in the file name the date and time
that the file was written.  So I also allow passing in a date format string
and a time format string.  If you are going to only do this once a week and
don't care about the time, then only pass in the date format.  If you are
going to do this several times in a day, then also pass in a time format.
 
The init function builds up a file spec which is the fully pathed location
of the file.  ATM it does not attempt to create the directory path to get
there, although eventually it will do that, so that if the path does not
exist it will attempt to build the path (directory structure).  
 
The log class has methods for recomputing the file spec, for example if the
time has changed.  There are a couple of simple methods for getting a read
or write text stream.  There are also properties for reading and writing the
file spec pieces individually if desired.  And finally there are two
properties to allow getting a pointer to the file system object, and the
text stream object.  Using the pointer to the text stream object, you can
then directly write to the log file.  Since the class holds the text stream
open until the class unloads or you intentionally close it, you can load
this class and just start writing to the text file.  Close when you are
done.
 
This class is an example of wrapping another object in order to extend that
object's functionality with your own.  As you know VBA does not directly
allow inheritance, however by using wrapper classes like this you can
crudely emulate inheritance.  I add functionality to the text stream object
here.  
 
To use the class you need to dim and instantiate the log class:
 
dim clsMyLog as clsLogFile
    set clsMyLog = new clsLogFile
    clsMyLog.Init(mclsLog.Init "C:\Dev\DISNEW\", "Test", "LOG", "YYYYMMDD",
"HHMMSS")
 
Now you are ready to write to the file.  Until such time as you unload the
class instance you can write to the text stream.
        
    clsMyLog.pTS.WriteLine "test"
 
clsMyLog gets a pointer to the log file class, pTS gets a pointer to the
open text stream, .Writeline calls the method of the textstream, and "test"
is written to the file.
 
The file name will look something like Test-20070106-105937.LOG and will be
located in the path C:\Dev\DISNEW\.
 
Throw this class out in your library, expose it, and use it as needed.
 
BTW, for those of you who follow the concept of a framework, I have a
framework object which is itself a class.  I have now built a new method of
the framework object that can initialize these log files and hold them in a
collection.  Given that my apps all use the framework, syntax becomes:
    
    cfw.log("MyLogName").Init("C:\Dev\DISNEW\", "Test", "LOG", "YYYYMMDD",
"HHMMSS")
    cfw.log("MyLogName").Log "Write some test text"
    cfw.log("MyLogName").Term        'closes the log file and unloads it
from the framework collection
 
Notice that this syntax looks strikingly similar to the syntax you would use
to work with any other object such as the database object, the form object
etc.  My framework is just an object, with methods and properties.
 
The first line causes the framework (cfw) to create an instance of the log
class, initialize it with the filespec information, and store a pointer to
the log class instance in a collection for future use. The second line uses
a previously initialized log class instance to write text.  The last line
unloads the class from memory and the collection of log files available for
use.
 
Doing things "the framework way" allows me to create a ton of log files as
required.  For example:
 
'
'From inside of the ULLICO export process class I call the framework and set
up two log files.
'
    cfw.log("ULLICOExport-Error").Init(C:\Dev\DISNEW\Export\ULLICO\",
"ULLICO-Error", "ERR", "YYYYMMDD", "HHMMSS") 
    cfw.log("ULLICOExport-Data").Init(C:\Dev\DISNEW\Export\ULLICO\",
"ULLICO-Data", "DAT", "YYYYMMDD", "HHMMSS")
 
'
'From inside of the HV Export class I call the framework and set up two log
classes.
'
    cfw.log("HVExport-Error").Init(C:\Dev\DISNEW\Export\HV\", "HV-Error",
"ERR", "YYYYMMDD", "HHMMSS") 
    cfw.log("HVExport-Data").Init(C:\Dev\DISNEW\Export\HV\", "HV-Data",
"DAT", "YYYYMMDD", "HHMMSS")
 
Now I have two different processes (a ULLICO export process and a HV export
process), each using two log files.  The Error log file is used to log any
processing errors that the export process runs into.  The Data log file is
the actual data file that is being assembled by the export process.
 
BTW, It took me almost as long to write this email as it did to write the
log class and hook it into my framework.  Classes are simple to write and
use once you understand them.  A framework magnifies the effectiveness of
service classes such as this log class enormously, making them dead simple
to set up, use and tear down.  
 
That's how I do it.
 
Class text to follow.  The message was too long to get by all in one piece.
 
John W. Colby
Colby Consulting
www.ColbyConsulting.com