Resolving a change conflict with KeepCurrentValues mode causes an exception when a timestamp property exists

Question

Hello

 

If I try to resolve an ObjectChangeConflict with a RefreshMode of KeepCurrentValues, for a User entity that has a timestamp property called Version, and then submit changes, an exception is thrown with the following message:

 

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

 

The exception makes sense to me in that the client should never update a timestamp, but it seem that LINQ to SQL does try to in this scenario. Is this a bug? Are other people getting the same exception?

 

Cheers

Andrew

Answer 1

This is a Beta2 bug that has been fixed for RTM.  The issue was reported in this forum recently by another as well - see thread http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2111581&SiteID=1&mode=1.  The issue is that KeepCurrentValues is causing us to keep the current timestamp version, meaning when it is compared against the current version newly read from the database, it's interpreted as an update.  For RTM, for all RefreshModes we will sync all db generated members (members marked IsDBGenerated = true) into the object being refreshed, so they are never interpreted as updates.  One workaround would be to refresh your Version member individually using RefreshMode.OverwriteCurrentValues, and use KeepCurrentValues for the rest. Thanks for reporting this.

Answer 2

This problem also occurs when KeepChanges is used as the RefreshMode.

Answer 3

Mathew,

 

Did you actually try out the workaround? It didn't work for me.  I tried the following:

 

Code Block

do

{

try

{

db.SubmitChanges(ConflictMode.ContinueOnConflict);

}

catch(ChangeConflictException)

{

foreach(ObjectChangeConflict cc in db.ChangeConflicts)

{

foreach(MemberChangeConflict mc in cc.MemberConflicts)

{

object[] attributes = mc.Member.GetCustomAttributes(typeof(ColumnAttribute), false);

if(attributes.Length > 0)

{

ColumnAttribute attribute = (ColumnAttribute)attributes[0];

if(attribute.IsDbGenerated)

{

mc.Resolve(RefreshMode.OverwriteCurrentValues);

continue;

}

}

mc.Resolve(RefreshMode.KeepChanges);

}

}

 

continue;

}

 

break;

} while(true);

 

Though the ChangeConflictException was properly handled, the InvalidOperationException is thrown when db.SubmitChanges() is called the second time with the error message: A member that is computed or generated by the database cannot be changed. 

 

It appears that RefreshMode.OverwriteCurrentValues did not do the trick.