Nice post! I have a few comments though…

“In this case, the support for a TRIGGER on Instance Startup to run”

Well, you can actually do this, kind of:

http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_init-file

“I want to keep a history of all changes to two tables, and have a means of viewing this history.”
and
“An alternative is to keep a full copy of all versions including current in the Audit Table.”

I don’t see you keeping track of the DELETEs. You can of course query it and deduce that a row must have been deleted, but it seems more sensible to ensure the history database is a full history, including DELETE events (so you can reconstruct the current situation from a history database alone). Of course that would involve another TRIGGER.

Another thing I was wondering about is why you don’t add at least a datetime or timestamp, and possibly other data such as current user, user host etc. to the audit tables. I mean, if you see something strange, You’d like to know when it happened, and who did it, no?

“I do not generally like to use ‘SELECT *’ however in this situation, the trigger is significantly simplified. This is of benefit if you are maintaining audit triggers on many tables.”

mm, personally I don’t like this trigger code that much…For each updated or inserted row you select the current row from the table…why? All data for the current row is available in the NEW.% columns, so there is no need to query anything…If is of course tedious to type all that, but you can easily generate the TRIGGER code from the I_S. Once you write that script, you can easily extend the history to include more tables as a bonus…

see: http://www.quest-pipelines.com/newsletter-v6/1005_A.htm

(spirit of the code is there, not sure if everything works)

kind regards,

Roland