When I read this article, it seemed like an absolutely correct concept for METADAT tables.  I think it grossly inefficient for large DATA tables, hoewever.) Except:

1.  It never showed either the original inserted or complete deleted record.  Fields are shown only for updates.  Adding the fields for deletes shouldn't put too much burden on the system on tables that have a small portion of deletes. 

2.  Assembling views of a record at any point in time would take some (clr) programming, but the logic could be built once and used for all tables.

3.  Similarly, the difficult logic of using an audit trail to rollback a table to some pervious state could be programed just once for all audited tables.

4.  It simplifies the task of identifying all the changes made by an individual during a time frame regardless of the table involved.  I think this single source is a good auditing tool.

My biggest problem, however, is that I can't make it work.  WHen I try to compile just the shell of the code, I find the compiler will not allow me to skip the Target attribute in

    <Microsoft.SqlServer.Server.SqlTrigger(Name:="AuditCommon", Event:="FOR UPDATE, INSERT, DELETE")> _

  I wonder if this article, which was originally written before SQL2005 was released, is now out of date and MS no longer allows it.  It seems the author anticipated this when he wrote:

''' Note that the "SqlTrigger" attrbute does not contain one of its normal tags; namely it does not

    ''' specify any particular table. We don't know if it is Microsoft's intention to allow table-agnostic

    '''trigger code, but this works and we hope that it keeps working.