locked
LINQ Version number for conflict detection RRS feed

  • Question

  • User274823782 posted

    Hi all,

     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;
                this.ExecuteDynamicUpdate(instance);
            }

    When I tried the following settings for the UpdateId column, I got a conflict error due to my manual updating of the UpdateId

    UpdateCheck = Always

    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?

    Regards

    Alan

     

     

    Thursday, January 8, 2009 10:10 PM

Answers

  • User-1376305016 posted

     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 field:

    • Timestamp: true
    • Auto-sync: OnUpdate
    • Auto generated value: true
    • Update check: never
    • CLR Type: System.Data.Linq.Binary

    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 :)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, January 9, 2009 2:46 AM

All replies

  • User-1376305016 posted

     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 field:

    • Timestamp: true
    • Auto-sync: OnUpdate
    • Auto generated value: true
    • Update check: never
    • CLR Type: System.Data.Linq.Binary

    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 :)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, January 9, 2009 2:46 AM
  • User274823782 posted

    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.

    Sunday, January 11, 2009 4:12 PM
  • User1432971339 posted

    Hi

     

    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 :

    http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.columnattribute_properties.aspx

     

    Regards

    Ali Kolahdoozan

     

     

     

    Saturday, January 8, 2011 10:19 AM