Library tutorials & articles
Using Triggers to track database action history
- Introduction
- Create tables
- Create triggers
Introduction
Several State and Federal contracts that I have worked on in the past have
wanted to keep track of all changes to a particular record, such as who modified
the record, what kind of modification took place, and when the record modification
occurred. I decided to solve this problem with triggers because I wanted to
capture every action that occurred on a particular table. For those unfamiliar
with triggers, a trigger is a database-event that fires when a particular action
occurs. For example, an INSERT trigger would fire when a particular database
table has a record inserted.
The Web application that needed to track all database actions was an ASP Intranet
application connected to a SQL Server 7 database, using NT Challenge/Response
authentication. There were many database tables in this application, but for
this article, we'll just examine one particular table and how I managed to track
the history for this table. Applying this technique to other database tables
is trivial.
Note: A database trigger only fires once per statement;
therefore, if you perform a mass update or mass delete then those instances
will not be recorded for each record. Keep this in mind when you develop
your own triggers.
Related articles
Related discussion
-
How to Databind PictureBox to database
by amazingpeople (0 replies)
-
Java Based Mobile Development Tool Now Supports Wireless PDA Access To SQL Server Databases
by mobiforms (0 replies)
-
Access SQL Server From Any Mobile PDA
by mobiforms (0 replies)
-
index out of range
by diwa.net (2 replies)
-
Index out of Range
by kausar4u (4 replies)
Related podcasts
-
Stack Overflow: Podcast #28
This is the twenty-eighth episode of the StackOverflow podcast, where Joel and Jeff discuss Windows Azure, SQL Server 2008 full text search, Bayesian filtering, porn detection, and project management — among other things. Jeff met the inestimable Joey DeVilla aka Accordion Guy...
Related jobs
-
Microsoft .Net Architect
in AMSTERDAM (€50K-€90K per annum) -
Ervaren SAP Basis Consultant
in Amsterdam (€50K-€90K per annum) -
Microsoft Dynamics CRM Consultant (Senior)
in Netherlands (€50K-€90K per annum) -
Microsoft Dynamics CRM Technical Consultant
in Netherlands (€50K-€90K per annum)
Events coming up
-
Mar
23
DevWeek 2009
London, United Kingdom
DevWeek is Europe’s leading independent conference for software developers, database professionals and IT architects, and features expert speakers on a wide range of topics, including .NET Framework 4.0, Silverlight 2, WCF 4.0, Visual Studio 2010, RESTful services, Windows Workflow, ASP.NET AJAX 4.0, SQL Server 2008, LINQ, C# 3, .NET Patterns, Ruby, and more.
Hai Tal
This Complete structure of the trigger and the table is fine...... this works fine and it will be good for one table.... but it will more fine and efficient if u embed all the operation info into one single trigger and run it up al at once.........
Oh, no.... I didn't say anything about using a cursor. There's no need for the RBAR (pronounced "ree-bar" and is a "Modenism" for "Row By Agonizing Row"). Do it all using proper set based techniques.
Hi Tal,
Jeff is right. Just declare a cursor that iterates over the inserted/deleted table. It should fetch at least your PKs, which you can use to retrieve the inserted/deleted lines - one after another.
However, your example is very sufficent and helped me a lot.
Thanks, Sven
Hi Tal,
You wrote "Note: A database trigger only fires once per statement; therefore, if you perform a mass update or mass delete then those instances will not be recorded for each record. Keep this in mind when you develop your own triggers. "
If you write your audit triggers to do an INSERT/SELECT from the INSERTED or DELETED table available in the trigger, then all records of a "mass update" or "mass delete" will be properly recorded in the audit table.
This thread is for discussions of Using Triggers to track database action history.