This project is read-only.

Handling System.Data.OptimisticConcurrencyException - Issue?

Mar 18, 2013 at 10:13 PM
Hi,

I don't know if this is an issue or whether I need to handle this exception being raised.

Assume I have 2 tables (for simplicity sake):

TableA
Id - int (identity)
Name - varchar(10)
TableBId - int

TableB
Id - int (identity)
Name - varchar(10)

TableB is basically a lookup table for TableA.

Now I've set both tables up with Allow Timestamp set to true in the designer.

When I create my context, I am setting the MergeOption to OverwriteChanges as follows:
_context.TableB.MergeOption = Objects.MergeOption.OverwriteChanges
// don't set TableA merge option
If I update TableA (change name) from my code and update TableB in SQL Server (changing the name) then OptimisticConcurrencyException is thrown when I call _context.SaveChanges().

Do I need to handle events where other users may change data? The lookup link has not changed - just the TableB record - but I am not bothered about what is in TableB record.

Any thoughts?

Thanks,

Andez
Mar 18, 2013 at 11:16 PM
I have had a look further at this.

If I add a new instance of TableA and assign to an existing instance of TableB, then the timestamp in the TableB record Timestamp is updated although it has not changed.

Before Save
0x00000000000036CE

After Save
0x00000000000036D0

Even though there is no modified state entries for TableB.

Andez
Apr 23, 2013 at 7:09 PM
Thought I'd give this thread a bump. Are you ok CodeTools?

Issue I have is a create a new instance of Table A as above. An existing instance of Table B is assigned to Table A. When I save, the Table B instance appears to be updated.

Is this by design?

Thanks

Andez
Apr 27, 2013 at 2:07 AM
If I understand you right, when data in the database changes unknown to code, your code errors. Is this right? If so this is by design. Otherwise you will get the lost update problem. It could very well be from 2 instances of your application. In any case. The timestamp in code must match the one in the database. This is the whole point of having a timestamp. If you do not want to use concurrency tracking, please turn off the timestamp on the appropriate table. Is this the problem?
Apr 28, 2013 at 5:10 PM
Hi codetools. I am fine with the concurrency part and the timestamps. I understand the use of the timestamp and concurrency. I have done a few systems before using this. The title of this thread is a little misleading after I did more investigation. It is more when should a timestamp get updated. Ignore my initial posting. I will hopefully make clear the question/issue in this post.

The question that I have is that when I make the changes to Table A, the timestamp in Table B is updated. I am not making changes to Table B. This is when Table A has a reference to a record in Table B. See if I can make it a little clearer.

So given the following:

TableA
Id - int (identity)
Name - varchar(10)
TableBId - int
Timestamp - timestamp
TableB
Id - int (identity)
Name - varchar(10)
Timestamp - timestamp

Table A Data
See sample data

Table B Data
See sample data

So from the screenshot data, if I update Peter record in Table A in code, then the timestamp for Jane is also updated in Table B - but Jane's record has not been updated from my code. I was not expecting the timestamp for Jane to get updated in Table B.

This occurs in a single application instance.

Cheers

Andez
May 4, 2013 at 11:42 AM
Hi,

If I may add to this conversation, do you have any idea whether this exception is related to the Entity Framework bug described in the following links?

http://stackoverflow.com/questions/9842555/hotfix-principal-entity-in-an-sql-application-generates-unnecessary-updates-d

and

http://support.microsoft.com/kb/2390624

Best regards,
Alex
May 4, 2013 at 2:55 PM
Hi Alex,

Thanks for the information.

I am using .NET 4.0. I contacted MS support as per instructions to obtain the hotfix. I got sent a link to down load it which resulted in a file NDP40-KB2390624-IA64.exe being run.

However, when I ran it I got:

KB2390624 does not apply, or is blocked by another condition on your computer.

Under C:\Windows\Microsoft.NET\Framework64\v4.0.30319, System.Data.Entity.dll is at version 4.0.30319.1.

The hotfix version mentioned in your link is 4.0.30319.359. So I think I need to get this on somehow.

The support guy said I should contact "our Microsoft Professional by call on 0844 800 2400, as they are best equipped to address your concern. The lines are open from 8.00 A.M to 6.00 P.M Monday to Friday. Telephone traffic is at its lowest early in the morning."

Regards,

Andez
May 4, 2013 at 7:25 PM
Hi Andez,

I have not applied the hotfix myself, so I do not know the version details you are mentioning. I am rather new to nhydrate and did not know if this was really the issue, I have happened to come across the optimistic concurrency ecxeption myself, and googling gave me the links above. I just mentioned it in case you haven't come across it and this could be of any help.

My experience is that the exception happens only the first time I try to save changes after I have opened a form. If I handle the exception with context.Refresh and then save, after that in following save operations the exception is not thrown.

All the best,
Alex
May 4, 2013 at 7:34 PM
Hi Alex,

It is not so much the exception. Just when I update an entity, it updates timestamp I have on related entities, even though I have not modified the properties.

But what you pointed me at could be the issue.

Cheers

Andez
May 5, 2013 at 7:34 PM
Hi Alex,

I am 99.9% sure this is the bug you have described with the Entity Framework.

I have just setup my Windows 8 environment running VS2012 with .NET 4.5 and this issue does not appear on this. When I update my Table A as I have been doing, the timestamp in Table B remains the same.

Thanks for that nugget of information.

I think I will force users to get to .NET 4.5 now. Onwards and upwards.

Cheers

Andez
May 6, 2013 at 8:35 AM
Hi Andez,

Glad you have solved the problem and that I have been of some help!

Sooo, VS2012... And .NET Framework 4.5...
Does this mean Entity Framework 5 ? Is nHydrate compatible with that?

Unfortunately I do not have VS2012 though. Any idea if all this configuration
works in VS2010 ?

Best regards,
Alex
May 6, 2013 at 12:18 PM
There was one issue I had with VS2012. I installed it on the same machine as my VS2010. It broke some Toolbox items.

And it broke nHydrate (see Issue but that was down to a stored procedure I had which returned a value. Basically I created the stored procedure in my database then imported the model. Codetools had a look and it needed a field manually adding in the model view and it worked.

I think the latest version is compatible with 4.5. As for using EF5 in VS2010, I have not tried. I am trying to move from VS2010 as VS2012 rocks!!!! I've never been happier with a VS version. Especially with the addons and extensions available.

I've in the process of writing an ASP.NET application to run under SharePoint 2010 and it is so easy once you overcome the few hurdles and gotchas.

Cheers,

Andez
May 11, 2013 at 10:30 PM
After finally getting passed from pillar to post number of Microsoft Agent's to try and get this hotfix, I finally received it in both x86 and x64 versions - not Itanium which the first agent sent last week. I ended up on the phone for 16 minutes so I hope I don't get charged an arm and a leg. They could have just had a link for this on the KB article.

Anyway, I am pleased to say having finally installed the 64-bit version, the issue has been resolved. Although they did say and made it clear that the hotfix had not been fully regression tested. I can't see this breaking anything to be honest - but I've said that about my own code and got bitten on the proverbials.

Andez