Last post Jan 08, 2011 10:19 AM by alikolahdoozan
Jan 08, 2009 10:10 PM|alangrutter|LINK
I am a little confused by LINQ to SQL conflict detection. I know that in order to use the Attach(obj, true) method on a disconnected object, the table must have a 'timestamp/version' column. In our database we have an UpdateId column that is supposed to
be incremented every time an update occurs. It is not an autonumber column.
At present, this column is configured in DBML as
UpdateCheck = Always
Timestamp = false
Auto Generated Value = false
Auto-Sync = false
and we have partial functions for each table where X is the table name) that look as follows to maually update the UpdateId:
partial void UpdateX(X instance)
instance.ModifiedDateTime = DateTime.Now;
instance.UpdateId += 1;
When I tried the following settings for the UpdateId column, I got a conflict error due to my manual updating of the UpdateId
Timestamp = true
Auto Generated Value = true
Auto-Sync = true
so I removed the UpdateId += 1 line from the code. When I do this, I no longer get an error and when SubmitChanges is called on the DataContext everything updates correctly in the database EXCEPT the UpdateId which never gets changed.
Is this a misunderstanding on my part or am I missing something vital in the setup / code which will make the UpdateId update whenever SubmitChanges() occurs?
LINQ SQL versioning
Jan 09, 2009 02:46 AM|elkdanger|LINK
The way we accomplish this is to set the field type of the field in the database you want to use for versioning as the 'RowVersion' type, rather than an auto-incremented integer. Then, if you delete and drag that table back onto your Linq To Sql desginer,
the field properties will be set up correctly. If you can't just delete and drag it back on (because perhaps you've made some other changes to the entity through the designer) then I believe the following properties must be set when you manually add the timestamp
Note that if you're using a timestamp field, then all the fields in that entity should have it's Update Check property set to 'never'. I'm not sure if this is a necessity, but this is what the designer does if you were to drag on the table which contained
a rowversion field.
After this you don't need to manage the row version field at all, except if you are calling Attach on the data context once the entity has been edited through the UI (as opposed to reloading the entity then applying changes). In this case you must store
the original timestamp somewhere when the entity is first loaded before editing, then restore it before you attach it to the data context.
Hope that helps. This should at least get rid of those cumbersome partial methods for you anyway :)
Jan 11, 2009 04:12 PM|alangrutter|LINK
Thank you for your answer - I think the key item I was missing was that the column in the database was not set up as a timestamp/rowversion column.
Jan 08, 2011 10:19 AM|alikolahdoozan|LINK
If I Have A Sqldatareader or datatable that fill with
GetSchemaTable How Can I know That 1 field must have which
propertys and value of each property ? you can see that property list in :