I have been tasked with developing a solution that tracks changes to a database.
For updates I need to capture:
- date of update
- old value
- new value
- field affected
- person doing change
- record id
- table record is in
For deletes:
- date of delete
- person doing delete
- The title/description/id of record deleted. The tables I am tracking changes on all have a title or description field. I'd like to capture this before the record is deleted.
- table record was in
For inserts:
- date of insert
- person doing change
- record id
- table record is in
I've thought of a few ways to do this:
- I am using stored procedures for any updates/deletes/inserts. I would create a generic "tracking" table. It would have enough fields to capture all the data. I would then add another line in each stored proc to the effect of "Insert record into tracking table".
- downside: all updates/deletes/inserts are all jumbled in the same table
- lots of NULLed fields
- how do I track batch updates/deletes/inserts? <---- this might not be an issue. I don't really do any thing like this in the application.
- how do I capture the user making the update. The database just sees one account.
- edit a lot of existing code to edit.
- Lastly, I could create a trigger that is called after updates/deletes/inserts. Many of the same downsides as the first solution except: I would have to edit as much code. I am not sure how I would track updates. It doesn't look like there's a way using triggers to see recently updated records.
I am using asp.net, C#, sql server 2005, iis6, windows 2003. I have no budget so sadly I can't buy anything to help me with this.
Thanks for your answers!
I would suggest you to use 2 column's in every table. names rowhistory and IsDeleted and the data type will be xml and bit. Never delete the rows, always use flag IsDeleted Now go with update triggers. I will give you example for the same I have this one table called Page
Now after creating the table all you need to do is copy paste the below code and your task is done for Page table. It will start recording the history of the row in the same row which is updated along with old and new values.
Now whenever you will perform any update your data will be stored in rowhistory column
One way I've seen this handled (though I wouldn't recommend it, honestly) is to handle it via stored procedures, passing in the userid/username/whatever as a parameter. The stored procedures would call a logging procedure, which wrote the relevant details in a central log table.
Here's where it got a bit whacky, though...
For INSERTs/UPDATEs, the relevant row(s) were stored in the table as XML data once the INSERT/UPDATE had completed successfully. For DELETEs, the row was stored prior to the DELETE running (though, realistically, they could have gotten it from the DELETE statement's output -- at least with SQL Server 2005).
If I remember correctly, the table only had a couple columns: UserID, DateTime of the logging, Transaction Type (I/U/D), XML data containing the relevant rows, table name, and primary key value (mainly used for quick searching of what records they wanted).
Many ways to skin a cat, though...
My advice is to keep is simple. Expand it out later if/when you need to.
If you have the ability to do so, lock down users to only be able to perform actionable statements on tables via stored procedures and then handle the logging (however you want) from there.