1
votes

I am working with an Actian Pervasive (v12) database and Entity Framework 6 and trying to insert a new record. When I do this, I receive a OptimisticConcurrencyException error. This behaviour does not happen when I use a MS SQL Server database, even though the tables are constructed the same and both have database generated identity fields.

In order to work around this problem I tried changing the [DatabaseGenerated] attribute on the Key field to all the different available values to see if it would behave better and not return the Exception (the Exception is invalid - I am the only user, and I am doing a single insert operation). This didn't help.

As a result, I would like to TURN OFF optimistic concurrency in Entity Framework (i.e. I WANT any updates I do to overwrite whatever is currently in the database). I do not want Entity Framework to raise this OptimisticConcurrencyException. The problem is, I'm not sure how to do this. My class definition does not currently have a TimeStamp field or any fields with the [ConcurrencyCheck] attribute, and yet it still raises this exception when I perform a simple insert.

Note: My application is developed using DevExpress XAF which is a framework on top of ASP.NET and Entity Framework, so the calls to retrieve data are automatically generated, and it is not easy to override these calls to catch and handle this exception, so I am trying to find a way to prevent Entity Framework from even raising this exception.

How can I turn off optimistic concurrency checks in Entity Framework (globally for my application)?

1
The exception in this case is misleading. Most likely caused by the data provider - EF expects the insert command to also return the newly inserted PK. - Ivan Stoev

1 Answers

0
votes

I found the solution.

Something I failed to mention in my initial description of the problem is that I am getting this error on classes that have mapped Insert procedures.

The exception being raised by EF (OptimisticConcurrency) was somewhat misleading in that the problem was actually that the new ID of the item was not being returned by the stored procedure (Ivan's comment got me thinking about the return value of the sproc).

To fix the problem I had to return the new ID from the stored procedure as follows:

SELECT @@IDENTITY AS ID;