Comments on: How do I check for changes in a database on insert / update?

By: onilke

onilke — Fri, 17 Dec 2004 04:55:23 +0000

It depends on to what use you will put the fact of “changed”, and if any or specific change is interesting.

Each of the databases would need a way to make the change visible.

The before mentioned update fields are only interesting if your program checking for change is able to determinate that this is actually a new date or username. These fields never tell their former values, unless you keep an additional table of every transaction (you might need huge space for this!).

The simplest way I can think of, is to supply every interesting table with the boolean field “Changed”, being set to true with each insert or update AND reset to false by the program checking for change, after the fact of change is reported.

By: howard2nd

howard2nd — Fri, 05 Nov 2004 13:56:39 +0000

In ‘Access’ you have to do your own “transaction” tracking.
SQL Server can do tracking for you. In either case the “Update” fields are best practice for table design.

By: aussiemate

aussiemate — Tue, 02 Nov 2004 18:21:43 +0000

Most definitely, the field option, addition of fields; ‘lastUpdated’ and ‘updatedBy’; should be made a part of every p/t or full timer programmers approach. Having this structure in place allows laymen to query database tables, giving a much sought, management the ability to gain their own stats, as well as the usual monthly reporting.

remember KISS!

Mike

By: aussiemate

aussiemate — Tue, 02 Nov 2004 18:21:34 +0000

remember KISS!

By: stanton

stanton — Thu, 28 Oct 2004 08:01:18 +0000

I design all my tables with an Updated by field and an Updated date field. This way I can tell when the last time a record in any table was updated. This also helps with debugging problems.

Stanton

By: mattaux

mattaux — Wed, 27 Oct 2004 04:50:34 +0000

I would suggest storing the changes you make to the database in the database itself that way you have an historical record and an audit trail.

One way to do this is to create shadow/mirror tables of all the core tables in your database. These shadows would contain all the fields in the core table along with a seed, a record type, and some kind of work flow ID. Then, on INSERT, UPDATE OR DELETE commands, the application would write the record to the shadow before any amendments.

In this scenario you would also have a control type table which would record the user, start and stop times and the work flow id etc. The application would have to populate this at the same time.

Hope this helps