Re: LINQ for SQL Conflict Resolution

(inline)...

On Mon, 6 Apr 2009 17:07:23 +0200, Frans Bouma <[email protected]> wrote:

>I wonder why topic started hasn't consider an AFTER DELETE trigger instead
>for deletes? the code would become much simpler and still the deleted data
>is available for auditing purposes (in the trigger, similar to what it is
>now).
>
>Of course I'm not aware of what the auditing stuff contains so it might be
>more complex than that.

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.

However, it looks like in the absence of any other convenient solutions we're going to 'solve' the problem by abandoning the trigger and moving the auditing logic back to the business layer - so the business layer uses LINQ for SQL to delete the object in the DB and then separately use LINQ for SQL to write the auditing records to the DB.

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