[AccessD] Watching data

John W. Colby jwcolby at colbyconsulting.com
Sat Feb 28 13:54:58 CST 2004


Arthur,

It's never easy and this is especially not easy.  ;-)  A user can start to
edit a record and hit escape.  A user can start to edit a record and have
validation fail to allow the save, or the user can have a nice clean edit /
save.  Even in the case of a clean save, by the time AfterUpdate occurs the
previous value isn't available.  Thus you have to save the old value to a
temp location in BeforeUpdate and then save the old and new value to the log
table in AfterUpdate.

Now, what about forms where the form has more than one editable table
represented?  I have very few of those but I have one in particular where
the user wanted data from about 4 different (related) tables all available
in one screen and all editable.  So what is the PK?  In fact, what is the
table?  What about controls bound to queries with aliased fields where the
name was changed by the developer in the underlying query?  I HATE "one of a
kind, do it with code in this specific form, for this specific form"
solutions.  I prefer to take the time to figure out how to make it work
across a broad spectrum of situations if possible.

I asked awhile back if it was possible to "drill down" through a bound
control to find the table / field name of the field that a control is bound
to and was told it is indeed possible.  It seems that to do it right, any
changed CONTROLS would have to be "drilled down" to discover their source,
then that info (table / field name) as well as old/new values recorded in
the log file.

It just so happens that I have a form class and a control class for every
data aware control so I could have my form class' form events poll the
control classes to see which controls have changed, do the "drill down"
however that may occur, and record the results.  Or, every control class
could be taught how to record changes in the Change Log and then the form
would poll all the control classes telling them to LogChanges (if any).  I
think it would be easier to teach the control classes to automatically
record changes, then have the form just poll the control classes for old/new
values if they have changed, and have the form class do the logging.  In
either case, if I could figure out the drill down thing and get this
working, in essence I could turn on logging with a switch as the form loads.
In it's Open even tell the form class to turn on logging for this specific
form.

If you don't have a framework such as mine how do you do this?  For that
matter, if you DO have a framework such as mine, how do you do this?  ;-)
Curious minds want to know.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller
Sent: Saturday, February 28, 2004 5:05 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Watching data


How interesting and convenient that you should raise this issue, as I am
facing a similar problem on an inherited app. While I am free to
restructure it, I also don't want to destroy everything done by previous
developers (not least for political reasons, but also because I want to
deliver the solution as inexpensively as possible). So...

The table of interest contains several fields which can be changed, and
parallel fields recording the date they were last changed. Obviously I
can add some code to each of the first set's AfterUpdate event and
record the date. But I'm thinking that it would be way cooler to do it
all in the form's AfterUpdate event instead. IIRC I don't think that I
have ever used this event in all my years of Access programming.

>From this event, can you determine which fields have changed? For
example, the user changes five fields. Can I somehow obtain a list of
the changed fields? Maybe I want the BeforeUpdate event instead? Ideally
what I would like to do is let the user change anything, then write the
changes to an AuditTrail table or somesuch, having a structure something
like this:

Table
PK
FieldName
PreviousValue
NewValue
DateTime

Arthur

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Saturday, February 28, 2004 4:04 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Watching data


Well... the data isn't normalized to that extent, i.e. I don't have an
"Address table".  A claimant has a single address, and that is embedded
directly in the Claimant table.  Thus a timestamp would only tell me
that the claimant table had changed, not that the address portion of the
table had changed.  Maybe she got married and changed her name?  The
Date of Birth was corrected?  The name was mis-spelled and the
mis-spelling was corrected?

John W. Colby
www.ColbyConsulting.com






More information about the AccessD mailing list