Re: LINQ for SQL Conflict Resolution

> Yep, that's exactly it. The auditing stuff requires some data that only becomes available when the delete happens. If we simply deleted the record, then there would be no means for an AFTER DELETE trigger to access that data. OTOH an AFTER UPDATE trigger can get to that data because it has access to the value of the record after the update happened.

The AFTER DELETE trigger can still access the SELECT * FROM DELETED
pseudo-table inside the trigger.

Here are some links to a T-SQL script that will automatically add
auditing triggers to the tables in a database, if that's helpful.

http://www.nigelrivett.net/AuditTrailTrigger.html (generic for all
tables, doesn't work with compound primary keys)
http://sqljunkies.com/Article/4CD01686-5178-490C-A90A-5AEEF5E35915.scuk
(CLR-based, better detail)
http://www.simple-talk.com/sql/database-administration/pop-rivetts-sql-server-faq-no.5-pop-on-the-audit-trail/
(much cleaner, supports CPKs)

My personal favorite solution
http://www.codeplex.com/AutoAudit


On another tangent, you can also consider renaming your tables to hide
them behind views that automatically filter the soft-deleted rows...
make all your application code talk ONLY to the views and then you're
okay to prune the soft-deleted row anytime you want without the
application caring.

-- 
Marc C. Brooks
http://musingmarc.blogspot.com

NOT sent from an iPhone

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives