I am concerned about the incorrect and unsubstantiated statements made both in the article and by some of the posters.  By now, most of the mistakes have been corrected, but I really wish people would triple-check their sources and code before posting. 

There have been many articles written about triggers for auditing, and IMO, none can be used as a generic solution.  The issue of auditing the entire record vs. just the changed fields (MUCH more difficult)  is not usually addressed properly.  The issue of trigger (or SP) overhead for auditing is almost never analyzed with real data.  Rarely is the use of transaction log auditing discussed in any depth.  The issue of auditing "meaningless" foreign keys (and not the "readable" value fom the related tables) is a serious concern in these solutions.  The issue of "single table for all audits" vs. "one audit table per table" is another area that is usually ignored.

Like many others, I have created very complicated trigger-based and client app-based auditing solutions.  I have had to design my database tables and app from the ground up with my own style of auditing solution in mind.  In my case, that means I must have a single autoinc-integer primary key and timestamp for every table in the database.  For my purposes, the client app must be able to instantly pull up a list of all the changes to any record in a database of hundreds of tables.  The client app must also be able to generate a sequential list of all changes made to the database over an arbitrary time period, or made by an arbitrary user.  Obviously, most multi-table trigger solutions would fail in this scenario.  Transaction log-based solutions are one possible way to go here, but unfortunately I had to roll my own.

My point is this:  it's unlikely that an unmodified generic solution will work for any particular database.  OTOH, it's always nice to see how other people approach these problems - there's usually something to learn - even from the mistakes.