The scenario:
All changes made by the operator to the database through bound controls
through a datacontrol should be duly authorised, printed and have the
possibility to revert to the initial data.
Solution applied:
Temporary tables are used.  As soon a record is edited or deleted, a copy
of the original record is made and the new record is also inserted in the
temporary table.  A flag with 0-Normal, 1-New, 2-Edited, 3-Deleted is
maintained.
Problems:
(1)  Do you have a better solution?
(2)  VB keeps a copy of the original data of the record being edited in its
"copy buffer".  Anyone knows how to copy this copy buffer to a table?
(3)  Another issue...Every one says that the best way to manipulate
databases is to mix bound and unbound methods.  How to achieve this?

J C NEERUNJUN

I like to keep my audit data in separate tables.

I use two schemes depending on needs:

#1) The simplist scheme for me is to write the name of the updated
field, the table name, the record's key, old/new field values, userID,
and timestamp  to a single audit table that serves all production
tables.

#2) A more comprehensive and resource intensive method is to make a
second "AuditHistory" table for every table in the database and copy a
snapshot of each record's "old" state into the table before updating
it with a change.    This leaves more room for customized reporting
later.    Not always practical for high-activity databases.

-----------------------------------

re:(1) - - what is the timeframe it takes the user to print, authorize
and confirm their entry.  Are we talking minutes or hours or days?  Do
you want them to be able to sign-off in the middle of the transaction?

General comment - - be wary of the DataChanged property.  It actually
does not exist for combo boxes, and will return False even when the user
has changed the data in that field.  To get around this, and to provide
pre- and post-change data for our audit trail, we had to add what we
called "shadow boxes" (text boxes that are linked to the same fields as
their "real" textbox companions, but that are invisible.  We check the
value in these fields against the value in the editable textboxes to see
which fields the user has changed, and write the Pre-change data from
the shadow boxes and the Post-change data from the editable textboxes.
Seemed like way too much effort for what should be an easy task, but we
found no better way to feed the audit trail properly...

John
I am in fact making a parralell base.  All the tables have a tmp[tablename].
  As soon as the edit button is pressed the current record is copied to the
tmptable and the edited one when update is done.  for new records they are
saved in tmptable at update and deleted ones on deletion.  The reports will
be done from this tmptable.
The nightmare was to correctly administrate the edit and cancel.
This solution makes possible to revert to initial record.
All these edits,new,deletion were on a VB form.  I am now using the Sherida
data widgets.  An array of the SSGrid is applied on SSTabs (4 in fact).  It
simplified my coding and is more straight forward.
I have never had the idea of creating shadow boxes.
A question which I asked and had no answer up to now is about the VB copy
buffer.  The Sheridan SSGrid also has one.  The edited record is in a copy
buffer.  Thus all actions could take place just before update.  The two
records directed to the tmptable would be the uinitial and the edited one
from the buffer.

May I thank you for your very interesting suggestion about shadow
boxes...It has not fallen in a deaf year.
J C NEERUNJUN