I use a trigger that I modified from Pop Rivett's column (https://www.simple-talk.com/content/article.aspx?article=301#forum from 2006. Put the trigger on any table to be audited and you get one record per field changed. I'm not sure how it will work under real load, hopefully it'll be OK. Since we're dealing with student data and some medical and related info, we want the ability to see changes over time and to be able to undo intentional corruption if a user decides to screw with the system. Multiple tables all go in to the same audit file which gives me a solid timeline if something goes bad, and the trigger has code for me ignoring fields or certain data types if I so desire.
The audit table looks like this:
I have another table and wrapper system similar to Kristen's for monitoring the execution of SPs. I only have four SPs currently, two that can be run by certain types of users and two that are run by the system on 12/31 and probably 09/01, so that's not as important.
I do like these as we'll be able to see changes over time. I want to have a question mark icon next to certain fields so that the history of that field can be viewed, but that's a feature for much further down the road. The elements are there, I just have to get the code working in the front end app.
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]