[AccessD] Watching data

David,

Thanks, the article does discuss the pitfalls and the concepts of auditing
changes, the fact that is just part of the table is irrelevant.

I am a framework kinda guy so I always think at the "make it a part of the
framework" so that it is available to the next form / project.



John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of David Beckles
Sent: Saturday, February 28, 2004 6:41 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Watching data


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


--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com