<bv***@hotmail.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...
Greetings,
I have a simple html/asp form that submits data to an access DB. The
idea is
when calling a record back from the db, the page will have an option to
change certain fields (drop down) then a new submit option.
My question at this point would be what logic or commands would I use
to compare the original data in the fields to what's being submitted. I
ultimately want to preserve the original records and somehow append
data that changes only. I'll need to eventually call a record and see
all the changes/updates made.
Someone mentioned I would prob need a couple of tables with a link
(relationship) but is it possible to dynamically create fields as
changes are made?
No. How many fields would be changing in a single post?
Here are two choices:-
1).
Have a second table which is identical to the first except it has version
number field added to the primary key include a version number on the
original table but do not add it to the primary key. After an update
happens on the table (the version number is incremented as part of the
update) make an insert to second table verbatim from the row that was just
updated. It's simple and effective but can make the DB large due to some
duplication of field values that have not changed, which in Access may be a
concern.
2).
Another choice is to have second table which includes the same fields that
make up the PK of the original table and adds a version number to them which
is also included in the original table. This table has a FieldName column
to contain the name of a field that is changing. It also has a value column
which contains a string that represents the value of the field for the
version.
When an update occurs allocate the next version number for the record to be
updates. Then compare the string version value of the each field being
updated with the incoming changes, if different insert a new record to the
second table with the PK of the record being updated, the new version
number, the field name and the new string value. After all the changes have
been logged make the update itself.
This approach suffers from complexity and results in values being stored as
strings rather than their native types. Also the more fields that change
per update the more duplication of PK and version number there will be.
That combined with using a string to represent data which is often smaller
in it's native type may mean this approach will also bloat your DB.
If you do use any of these approaches use a transaction to make the updates
atomic.
I prefer (and have used albeit in SQL Server) approach 1.
Thanks in advance,