Hello Kevin,

Yes, you are right. It was only the generic trigger and we also were thinking about creating and extended property for columns so we can put or remove a checkmark to indicate the "audit log" is enabled/disabled for that column.

I will keep in mind your recommendation to generate the trigger without including dynamic SQL. They will be large but they will run faster?

Thanks.


> I found a generic trigger here: http://www.nigelrivett.net/SQLTriggers/AuditTrailTrigger.html
>
>Hi, Juan,
>
>If you're working with large tables that are updated frequently, I strongly recommend you do some extensive stress testing (including large simultaneous updates) with this approach before you put something like this into production.
>
>If you have a table with 20 columns, that means the server is processing 20 dynamic SQL commands - anytime a single UPDATE statement is issued.
>
>It's been reported that MS made some performance enhancements for dynamic SQL in SQL 2005 - but regardless...you may be better off identifying which tables/columns you want to log in an application level data dictionary, and then writing a script that generates your update triggers based on what you want to log.
>
>No need for dynamic SQL, and when your schema changes, all you have to do is re-run the script to regenerate your triggers.
>
>Kevin