Geek Answers Handbook

LINQ to SQL has disabled updating an object from different data contexts

http://geekswithblogs.net/michelotti/archive/2007/12/17/117791.aspx

I am using ASP.NET with C # and trying to use linq for sql to update the data context, as shown on the blog linked above. I created the timestamp field in the table in the same way as indicated, and use the following method:

private void updateRecord(TableName updatedRecord) { context db = new context(); db.TableName.Attach(updatedRecord,true); db.SubmitChanges(); }

My question is: do you need to assign the timeStamp field to something in your updated registry before trying to call the Attach method in the data context?

When I run this code, I get the following exception: System.Data.Linq.ChangeConflictException: Row not found or changed. I update all fields, including the primary key of the record I am updating, before passing the object to this update method. When debugging, the object's TimeStamp attribute is displayed as null. I'm not sure if this is so or not.

In every book and resource I tell, this is a way to do this, but not one of them went into details about this TimeStamp attribute.

I know this is quick and easy, so if anyone knows, please let me know.

+4
source share
2 answers

If you have a timestamp column, then to update the record (from the vanilla object): yes, I would expect you to have to assign it. Otherwise, you lose the ability to use a timestamp to optimize concurrency.

The idea is that you take a copy of the timestamp when you grab your (disabled) object, and then when updating you can use this column to make sure no one else has edited the line.

There are two common scenarios:

1: if you perform a short operation, first retrieve the record from the database - make changes to the object and just SumbitChanges () [all with the same data context]. The data context will handle concurrency for you.

2: if you disconnect the object (for example, passing it to the client application for a while), use something like serialization (LINQ-to-SQL objects support the DataContractSerializer (optional, you need to enable it)). Therefore, serialize the object on the server, pass it to the client - the client makes changes to its copy and passes it back. The server deserializes it and uses Attach () and SubmitChanges (). A record in memory should still have a timestamp that it had when retrieving from the database, so we can optimistically concurrency cover all the time when the record was disconnected.

+1
source

Since you say that you created a timestamp field in the table, I am wondering if, in the case when this column was added later, the properties of the column may not be set correctly. You can check the properties on the TimeStamp column in the DBML designer. Make sure that:

 AutoGenerated = true Auto-Sync = Always Time Stamp = True Update Check = Never

Server data type must be rowversion NOT NULL

If it is not configured to automatically create and synchronize always, the version of the row will not be returned from the insert, since you did not change it when the insert was completed. Although this value is generated by the database, the DataContext must know this so that it can correctly handle it.

Also, now that you have the timestamp column, UpdateCheck should be set to Never for all other columns.

+3
source

More articles:


All Articles