[AccessD] Audit Trail Suggestions

John W. Colby jwcolby at gmail.com
Sat Mar 14 21:11:36 CDT 2015


The class "wraps" a control.  Pass a single instance of a control into a 
single instance of a class.  Then the code to sink the events for that 
control is embedded in the class.  The code to log the data is embedded 
in the class and so forth.

If you have 10 text boxes, then you have 10 instances of the text box 
logger class, one for each text box.  If you have 13 radio buttons then 
you have 13 instances of the radio button logger class.  Etc.

You need a class for each type of control simply because the event 
sink(s) cannot be generalized. The control has to be passed in to the 
class "as textbox" or "as combobox" etc.

I actually did this as part of my framework and it works very well.

John W. Colby

On 3/14/2015 5:11 PM, David Emerson wrote:
> Hi John,
>
> Can you please expand on this: " Feed in the control to the class and then
> watch the events".
>
> Do you mean pass the control as a parameter to the class, or store the list
> of controls in the class?
> How are the events watched - by code in the after update?
>
> Regards
>
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
>
>
>
>
> -----Original Message-----
> From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> John W. Colby
> Sent: Sunday, 15 March 2015 9:44 a.m.
> To: Access Developers discussion and problem solving;
> jaydwhite at bellsouth.net
> Subject: Re: [AccessD] Audit Trail Suggestions
>
> I wrote a class set to handle this.  Feed in the control to the class and
> then watch the events.  Log changes.
>
> John W. Colby
>
> On 3/14/2015 12:21 AM, David Emerson wrote:
>> Hi Team,
>>
>> Looking for ideas for implementation.
>>
>> Access 2010 FE, SQL 2008 R2
>>
>> A client wants to keep track of some fields in some tables when they
>> are changed.  There are over 50 tables involved and anywhere from 3 to
>> 30 fields per table.  The tables and fields are predefined.  Most of
>> the data changes will be done via Access screens but there are some
>> fields that are changed through code
>>
>> When a field value is changed they want to store in a log table date,
>> person making change, old value, new value.
>>
>> Looking for ideas of how others might have tackled this type of
>> problem before.
>>
>> Regards
>>
>> David Emerson
>> Dalyn Software Ltd
>> Wellington, New Zealand
>>
>>
>>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



More information about the AccessD mailing list