System.Data.Linq.ChangeConflictException: Row not found or changed

Question

I am trying to delete a selected gridview row using LINQ (No LINQDataSource).

When the selection is changed, the detailsview binding is changed also. I can add a new

Answer 1

The problem could be also simply that the DBML definition of the table is not consistent with the status of the Database definition. I just removed the DBML model and inserted it again from the database, and it worked.

Hope this helps somebody.

Answer 2

Ensure that no columns contain null values in the related table (i.e. the table to be updated).

Answer 3

OK - it looks as though (in my case at least) the answer was to set all non primary-key column's UpdateCheck property to Never in the DBML file. Doing this immediately cured the problem of "Row not found or changed".

Given the rumour that Microsoft are moth-balling Linq-To-Sql in favor of Entity Framework, one wonders whether these sorts of bugs will be fixed?

Answer 4

You are getting this error quite possibly because one of your fields has something different in the Linq To SQL designer and in the actual database.

In my case, it was because one of the fields was nullable in the database and not nullable in the designer, making it nullable in the designer as well solved the problem immediately.

Answer 5

Seemed to work for my situation also. I was building an in memory, never before submitted row which had several foreign key relationships to rows in other tables. The InsertOnSubmit seemed to work but a subsequent DeleteOnSubmit was giving me that row not found error. I was not populating every field in the row I submitted so I don't know if that had anything to do with it but marking all of the main table's non-primary key columns eliminated the error message.

One further thought: I take it that marking a column's UpdateCheck policy as 'Never' means that it is not used as the basis for optimistic concurency checking. This would imply that two users could write over a given row with different data in any such column and the conflicts would not be detected...meaning the last user to submit the row would overwrite the values of the previous users submission. I gathered from various online reading that one partial solution to this is to use the Refresh method immediately before submission to sync up any changes. Of course with no pesimistic lock on the row there is no guarantee that the row won't still be changed between the Refresh and the Submit but in most scenarios involving large databases this would be rare.

Update: On further review I think I have discovered a scenario that may be affecting others so I thought I would share it just in case. It turns out that at least part of the trouble I have been having with SQL LINQ is related to triggers. It appears that if you submit a row using SQL LINQ and your DBA has triggers designed to write information to some columns in that row then the SQL LINQ model will by default 'Always' determine that the row has been changed since your last write of it. I was submitting partially populated rows and our DBA's triggers are filling in some columns so that when I attempted to further modify the row in our code it sensed a change conflict based on the columns populated by the trigger. I am investigating now the best way to handle this but changing these trigger populated fields to use an UpdateCheck policy of 'When Changed' or 'Never' worked for me. Hope it helps.

Answer 6

I got around this issue, by making sure to refresh my object immediately before updating it. I do this with the KeepChanges option.

    db.Refresh(System.Data.Linq.RefreshMode.KeepChanges, employee);