That is not a new requirement and many people have different approaches to it.
Take as starting point this article:
Here's another take on the audit log:
It is not a simple task. At heart, you need to cut off users ability to do ANYTHING to the data EXCEPT through interfaces that you have coded. Depending upon your present design that may be simple (you already have a healthy scepticism about users screwing up data and have built a UI that already controls data change) or hard ( you give users things like datasheet views and split forms where you the developer exercise no control)
You have seen two takes on this task. This tangentially is a third
What you do is put data in a ‘temp’ location and bind your form to the temp data each time the form loads. The users are then NOT mucking with the real data and you can code both the changes to the real data and the audit trail through events on the form ( a commit button perhaps)
No matter what, it isn’t a simple task, since YOU have to code all the CRUD operations yourself and twice — once for the actual data operations and once for the audit records
If all you're after is (a) what the data state was before the change and (b) what the data state is after the change, then the audit log methods suggested would suffice. Using temp-bound forms for situations like this is just overkill.
<grin>IF and it is a big if, you’ve built some fairly secure forms already, then staging data might be more work. If you’ ve got loosey-goosey forms, it might be less. Much too depends on how rigorous the data auditing needs to be
IT issues often require a personalized solution. With Ask the Experts™, submit your questions to our certified professionals and receive unlimited, customized solutions that work for you.
Take hold of your future.