none
LINQ update fails for concurrency issue RRS feed

  • Question

  • DataContext dt = new DataContext( SXADBAccess.OpenDBConnection());

                LinqManager<SXASRClients>.Update(client, dt); // this does attach operation
                try
                {
                    dt.SubmitChanges(ConflictMode.ContinueOnConflict);
    // same data has changed by some user before this submitchanges.
                }
                catch (ChangeConflictException)
                {
                    foreach (ObjectChangeConflict obj in dt.ChangeConflicts)
                    {
                        SXASRClients c = (SXASRClients)obj.Object;
                        obj.Resolve(RefreshMode.KeepCurrentValues);
                    }
               dt.SubmitChanges(); 
    //this submitchanges() Throws an error when conflict happens

    ERROR " Value of member 'timestamp' of an object of type 'SXASRClients' changed. A member that is computed or generated by the database cannot be changed."
                }



    This code works fine for normal updates without conflict.
    I think I missed decorating appropriate attributes on my class/properties

    Timestamp declaration is

            private byte[] m_timestamp ;
            [Column(AutoSync = AutoSync.Always, DbType = "rowversion NOT NULL", CanBeNull = false, IsDbGenerated = true, IsVersion = true, UpdateCheck = UpdateCheck.Never)]
            public byte[] timestamp
            {
                get { return m_timestamp; }
                set { m_timestamp = value; }
            }

    NOTE: This class is not generated by LINQ to SQL. I have written this class.
    It works fine for all CUD operation except conflict problem.



    Thanks
    Hasmukh

    Monday, September 3, 2007 11:28 AM

Answers

All replies

  • When I have specified all these attributes...

    [Column(AutoSync = AutoSync.Always, DbType = "rowversion NOT NULL", CanBeNull = false, IsDbGenerated = true, IsVersion = true, UpdateCheck = UpdateCheck.Always)]

    What is the reason for getting this error:

    ERROR " Value of member 'timestamp' of an object of type 'SXASRClients' changed. A member that is computed or generated by the database cannot be changed."

    Is this a Bug or am missing something?

    Thanks & Regards
    Hasmukh
    Tuesday, September 4, 2007 11:53 AM
  • I was wondering about my query.

    Whether its a dumb question or no one knows the answer!!


    Thanks
    Hasmukh
    Thursday, September 6, 2007 1:54 PM
  • You have IsDbGenerated set to true, so it appears that the database is inserting a value for you. This error is because you have programmatically changed a property called "Timestamp" on your object. It is warning you that you have modified a property that cannot be saved back to the database. If the database isn't generating this value, then remove IsDbGenerated = true
    Thursday, September 6, 2007 6:58 PM
  • I am not sure.
    when IsVersion=true, This timestamp will be used to check whether record is modified or not by third party.
    when IsDbGenerated = true. It never take my values, it will update its own.

    for conflicts, I think,

    It will take timestamp value for the first time and compare.. if it is same then it will update the records and update the timestamp by db itself.

    If records has been modified by someone else.. it will resolve the issue, and try to update the record.. update the timestamp by db itself.

    Once I mention
    IsDbGenerated = true, it never consider my timestamp values except for version comparison.

    I might have done some mistake.. but not sure what?

    Hasmukh
    Friday, September 7, 2007 10:20 AM
  • This is a bug in LINQ to SQL.  Thanks for reporting it.

    Friday, September 7, 2007 5:19 PM
    Moderator
  • Is this still a standing bug or is there a work around to this problem?

     

    Assigning the TimeStamp to a re-loaded record does not work if the record was updated and the time stamp has changed.

     

    This is causing major problems dealing with optimistic concurrency in a web app. I also don't want to rely on persisting my entities to ViewState or SessionState during a request since it will not scale well or create large web requests.

     

    Are there any suggestions on how to get around this problem?

     

    Wednesday, April 16, 2008 8:52 PM
  • I am in the same position, is there any resolution on this?
    Monday, April 28, 2008 8:53 PM
  • I have code that seems to be showing the same symptoms.

     

    I retrieve three records into 'Sales' enitities.

     

    I update the Sales.Amount on each record and submitchanges fine.

     

    If one of the 3 records is changed on the database in the interim period my try/catch correctly catches the conflict and resolves. When I subsequently re-submit (after resolving) I get the error...

     

    "Value of member 'TimeStamp' of an object of type 'Sale' changed.
    A member that is computed or generated by the database cannot be changed."

     

    After stepping through my code I see that the timestamps are changing after resolve is called. Surely this should not be the case (my Timestamp should only update AFTER a change is successfully posted to the DB I would have thought).

     

    Any update on whther this is a bug OR any other ideas?

     

     

     

     

    Monday, June 2, 2008 3:07 PM
  • This is a really horrible bug.. is there a workaround or a hotfix or anything?? It's been a year and a half.
    Wednesday, April 8, 2009 8:10 PM
  • I too am experiencing this at the moment. When are we likely to see a fix for this?
    • Proposed as answer by Tailslide Thursday, April 16, 2009 3:51 PM
    Thursday, April 16, 2009 8:08 AM
  • I found a workaround that appears to work for me:

    1. Change the timestamp field to autosync on insert.

    2. After you submit your changes, manually reload the timestamp field for updated records.

    Thursday, April 16, 2009 3:54 PM
  • I found a workaround that appears to work for me:

    1. Change the timestamp field to autosync on insert.

    2. After you submit your changes, manually reload the timestamp field for updated records.

    I found another solution.

    Just mark the timestamp field as readonly in your dbml.  This makes sure the timestamp field can't be altered by code and will only be updated by the DB.



    Wednesday, May 20, 2009 8:12 AM
  • I found another solution.

    Just mark the timestamp field as readonly in your dbml.  This makes sure the timestamp field can't be altered by code and will only be updated by the DB.




    I tried this in my project and I get the same exception as before.  I first tried saving a conflicting change, and overwrote the conflicting change with no error.  Then, when I tried another two changes, one of which conflicted with the DB then doing a merge changes I got the following exception:

    System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Value of member 'ModifiedStamp' of an object of type 'User' changed.

    A member that is computed or generated by the database cannot be changed. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:

    System.InvalidOperationException: Value of member 'ModifiedStamp' of an object of type 'User' changed.
    A member that is computed or generated by the database cannot be changed.
    at System.Data.Linq.ChangeProcessor.CheckForInvalidChanges(TrackedObject tracked)

     

    After I reverted back to syncing on insert only and manually reloading the timestamp I followed the same steps and there was no error.

    Wednesday, May 20, 2009 4:49 PM
  • Four Years, Two major versions of VS and a lot of .Net Frameworks releases and still having the same issue?

    Its is not possible at this day to change manually a simple Autogenerated value?

    Wednesday, November 23, 2011 4:52 PM
  • This is a bug in LINQ to SQL.  Thanks for reporting it.


    Two VS major versions, four years past, alot of .Net frameworks releases and until today is still impossible to change one autogenerated value manually...

    Why we dont have support for that?

    Wednesday, November 23, 2011 5:26 PM