Re: LINQ for SQL Conflict Resolution

On Thu, Apr 2, 2009 at 5:06 AM, Simon Robinson <[email protected]> wrote:
> I have a problem with a database update that is going through LINQ for SQL, via a call to DataContext.SubmitChanges().

I haven't worked with LINQ to SQL at all so take this with a grain of salt...

> For reasons to do with auditing, we never delete records in this table directly; if we wish to delete a record, we do so
> by updating it to set an IS_DELETED bit field to 1. This is immediately picked up by an AFTER UPDATE trigger
> which does various auditing actions and then deletes the record.
>
> The problem is this is throwing LINQ's concurrency processing: If I try to mark a record for deletion, the record isn't
> deleted, and SubmitChanges() throws the dreaded ChangeConflictException. The exception goes away if I
> comment out the line in the trigger that deletes the row.

Can you try issuing the DELETE statement with the UPDATE statement
within the LINQ submit? If you trust the trigger to occur, the DELETE
statement won't actually do anything, but if LINQ's concurrency
processing can be forced to only check after both operations, it
should then expect the row to be deleted.

-- 
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)

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