July 19, 2005 10:19 PM

Auditing Advice

Try these tricks for designing audit triggers
Rating: (0)
SQL Server Magazine
InstantDoc ID #46713
When you need to audit data changes, you face several challenges. The course of audit action you take might depend on the number of affected rows, the type of statement that modified the data, and whether you want to audit both successful events and failed events. Also, you might want to audit each attribute value change in a separate audit row. Dealing with such auditing issues can be tricky, and as you'll see later, you need to apply logic to come up with solutions. We'll look at a strategy fo...

...This article is for paid Professional Members only.

Already a Professional Member? Please log in now:

NOT A PROFESSIONAL MEMBER? YOU CHOOSE:

Professional Membership

Monthly

Annual

VIP Membership

Monthly

Annual

Add a Comment

I found a problem with the 'update' part of the trigger. This problem occurs when the source table is not using an IDENTITY value as the primary key. Say for instance we are using a varchar(11) as a unique primary key, and the primary key itself is changed (which can happen, SSN#, ISBN, etc). In this case an audit header row will be written, but there will be no audit detail rows because of the failure to match up primary keys in @inserted and @deleted. Is there anything you can suggest?

STEVEN1/3/2006 12:32:09 PM


You must log on before posting a comment.

Are you a new visitor? Register Here
GOOGLE LINKS
SPONSORED LINKS
FEATURED LINKS