[AccessD] Watching data

David Beckles becklesd at tiscali.co.uk
Sat Feb 28 05:41:05 CST 2004


An alternative approach, and the one that I use, is to audit all changes, 
along the lines given by Allen Browne in 
http://members.iinet.net.au/~allenbrowne/AppAudit.html. It is then a simple 
matter to produce reports on the changes to fields in the tables. Of course 
this assumes that all changes are made through the forms, or else that all 
code that updates the tables writes an audit trail. I use a class 
associated with the table to handle these. I think that this is a simpler 
approach than the one you have suggested (but that's just my opinion, 
probably because it is the one that I use.<g>)

I could give more details if you wanted.

I hope that this helps,
David



>Date: Fri, 27 Feb 2004 17:03:24 -0500
>From: "John W. Colby" <jwcolby at colbyconsulting.com>
>Subject: [AccessD] Watching data
>To: "AccessD" <AccessD at databaseadvisors.com>
>Message-ID: <DCEFJAOENMNENLAAOFGPKEDIGPAA.jwcolby at colbyconsulting.com>
>Content-Type: text/plain;       charset="iso-8859-1"
>
>I need a system for watching specific data fields in specific tables for
>changes.  For example, if the Policy holder address changes, the claimant
>address changes, the Payment location (address) changes etc.  If ANY of
>these change then I need to gather the information and at the end of the day
>email a report to the client (the insurance company) spelling out the
>changes, what object the fields belonged to (Claimant, Policy Holder etc.).
>
>Make sense?
>
>Of course I could launch into building code in every form I can find where
>these objects are used and this info can be saved.  However this seems like
>a "framework" kind of task.  I envision a class (let's call it
>dclsMonitorCtlChg for now) in the framework that the form class loads if a
>form class method (perhaps MonitorCtlDataChg(ParamArray varCtls as
>variant) ) is called with controls specified.
>
>The form class already has a collection of the classes for each control's
>class.  The form class MonitorCtlDataChg() could grab a pointer to each of
>the controls that this method says needs to be monitored and pass them to
>the dclsMonitorCtlChg which would place them in a collection.  Then a form
>event or events (Before update, After update) could call a method of
>dclsMonitorCtlChg telling it to "look for changes in your control set".  The
>class could raise an event or simply return a value to the form caller if
>any change was detected.
>
>Of course it would then be useful to know what controls (fields) were
>changed, the old value and the new value.  This would allow the application
>to generate a report:
>
>Object Monitored (Claimant)
>Field:  Addr1: OldValue: NewValue
>                 Zip: OldValue: NewValue
>
>IOW the claimant moved to a new location, but in the same city, just changed
>the address1 and the zip.
>
>So.... is anyone doing anything like this?  If so any words of advice,
>things to look out for etc?
>
>John W. Colby
>www.ColbyConsulting.com





More information about the AccessD mailing list