audit

One simple method I've used in the past is basically just creating a second table whose structure mirrors the one I want to audit, and then create an update/delete trigger on the main table. Before a record is updated/deleted, the current state is saved to the audit table via the trigger. While effective, the data in the audit table is not the most useful or simple to report off of. I'm wondering if anyone has a better method for auditing data changes? There shouldn't be too many updates of these records, but it is highly sensitive information, so it is important to the customer that all

I'm using NHibernate on a project and I need to do data auditing. I found this article on codeproject which discusses the IInterceptor interface. What is your preferred way of auditing data? Do you use database triggers? Do you use something similar to what's dicussed in the article? For NHibernate 2.0, you should also look at Event Listeners . These are the evolution of the IInterceptor interface and we use them successfully for auditing. [EDIT] Post NH2.0 release, please look at the Event Listeners as suggested below. My answer is outdated. The IInterceptor is the recommended way to modify

I need to create a database table to store different change log/auditing (when something was added, deleted, modified, etc). I don't need to store particularly detailed info, so I was thinking something along the lines of: id (for event) user that triggered it event name event description timestamp of the event Am I missing something here? Obviously I can keep improving the design, although I don't plan on making it complicated (creating other tables for event types or stuff like that is out of the question since it's a complication for my need). In the project I'm working on, audit log also

Every time I need to design a new database I spend quite some time thinking on how I should set up the database schema to keep an audit log of the changes. Some questions have already been asked here about this, but I don't agree that there is a single best approach for all scenarios: Database Design For Revisions Best design for a change log auditing database table Ideas on database design for capturing audit trails I have also stumbled upon this interesting article on Maintaining a Log of Database Changes that tries to list the pro and cons of each approach. It's very well written and has

How can I maintain a log of the data in my DB? I have to maintain a log of every change made to each row. That means that I can't allow DELETE and UPDATE to be performed. How can I keep such a log? Use "Insert Only Databases" The basic idea is that you never update or delete data. Each table has 2 datetime columns from and to . They start with the value null in each (beginning of time to end of time) When you need to "change" the row you add a new row, at the same time you update the to in the previous row to Now and the from in the row you are adding to Now. You read data out of the table via

I have my core project in C#. I work on a database, where some tables have the columns "user_mod" and "date_mod" for sign who and when made some mods and the same with "data_new" and "user_new". My question: is there a way to centralize this and make this data inserted automatically, where I create the instance of dbContext ? If not, I will use an audit trail tool. I have seen some of these, but there is a problem: all of these, require some code in my model. But I don't want to write in my model, because if I have to change it, I will lost the mods. Is it possible use an audit trail for EF6

I need to implement change tracking on two tables in my SQL Server 2005 database. I need to audit additions, deletions, updates (with detail on what was updated). I was planning on using a trigger to do this, but after poking around on Google I found that it was incredibly easy to do this incorrectly, and I wanted to avoid that on the get-go. Can anybody post an example of an update trigger that accomplishes this successfully and in an elegant manner? I am hoping to end up with an audit table with the following structure: ID LogDate TableName TransactionType (update/insert/delete) RecordID