Devart Forums

Posted: **Thu 23 May 2013 14:50**

I am using dotConnect version 7.6.226 and once in a while I get this below error. Can you please tell me how can this be fixed as this is currently in production environment. If its an error or bug from your end, then please advise, so that I know its nothing from our end. Also, one of your older post sometime in Oct 2012 Mariia from your Team, suggested in one of the post as below: (Do I need to do that?)

To avoid it, please set the Found Rows parameter to 'true' in the connection string in use (open Database Explorer->Edit Connection Properties-> Advanced) and save the changes. In this case, the number of rows matching the WHERE condition of the UPDATE statement will be returned by the provider.

The exact error which I am currently receiving is as below.

Code: Select all

Devart.Data.Linq.ChangeConflictException
Exception of type 'Devart.Data.Linq.ChangeConflictException' was thrown.

System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> Devart.Data.Linq.ChangeConflictException: Exception of type 'Devart.Data.Linq.ChangeConflictException' was thrown.
   at Devart.Data.Linq.Engine.SubmitCommandBuilder.a(String A_0, IEnumerable`1 A_1, IEnumerable`1 A_2, Boolean A_3)
   at Devart.Data.Linq.Engine.SubmitCommandBuilder.a(String A_0, IEnumerable`1 A_1, Boolean A_2)
   at Devart.Data.Linq.Engine.b4.a(IObjectEntry[] A_0, ConflictMode A_1, a A_2)
   at Devart.Data.Linq.Engine.b4.a(ConflictMode A_0)
   at Devart.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
   at Scribe.Articles.autosave.do_autosave(String title, String content, String sourcing, String extract, String date, Dictionary`2 others)
   at Scribe.Articles.autosave.Page_Load(Object sender, EventArgs e)
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.HandleError(Exception e)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Posted: **Mon 27 May 2013 07:08**

If you are receving this error in a scenario similar to your post in October, then this issue is on our side. We are working on it now and we will inform when it is fixed.

To avoid it, please set the Found Rows parameter to 'true' in the connection string in use (open Database Explorer->Edit Connection Properties-> Advanced) and save the changes. In this case, the number of rows matching the WHERE condition of the UPDATE statement will be returned by the provider.

Yes, please do this suggestion to avoid the error. As we have written you earlier, it occurs because you are trying to update the record with the same value. The Update command is sent to the server, but, since the old and new values are the same, the number of rows affected by the last UPDATE is equal to 0, and LinqConnect runtime considers this to be a concurrency conflict.

Posted: **Fri 07 Jun 2013 12:15**

Devart.Data.Linq.Binary type was added to the "Type Mapping Rule Editor" for working with binary columns. We recommend you to change the default mapping before creating a LinqConnect model via the Database-First approach in order to apply these changes to all properties of the model.
To do it:
- open Tools -> Entity Developer -> Options -> Server Options -> MySQL;
- set the .NET type to 'Devart.Data.Linq.Binary' for the Server Type 'varbinary';
- press 'OK' to save the changes.

Please test the new build of LinqConnect 4.2.262 with this change and notify us about the results.
It can be downloaded from http://www.devart.com/linqconnect/download.html (trial version) or from Registered Users' Area (for users with active subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?f=31&t=27292

Posted: **Thu 13 Jun 2013 15:47**

Thanks Mariial - Appreciate the response. BUT since its not easy to update our Servers running on Load Balancers on regular basis, I would opt out for now with the new version of dotConnect and stick to the one mentioned earlier in this thread.

Question: So the solution for the ChangeConflictException with Found Rows = 0 will suffice?

Please advise.

Thank you.

Posted: **Fri 14 Jun 2013 08:27**

This solution should be enough for you to avoid this error. After setting "Found Rows" parameter to True, the number of rows matching the WHERE condition of the UPDATE statement will be returned by the provider and update will be performed without ChangeConflictException.

However, we still recommend you to use a special type Devart.Data.Linq.Binary in such scenarios in the future.

Devart Forums

Devart.Data.Linq.ChangeConflictException

Devart.Data.Linq.ChangeConflictException

Re: Devart.Data.Linq.ChangeConflictException

Re: Devart.Data.Linq.ChangeConflictException

Re: Devart.Data.Linq.ChangeConflictException

Re: Devart.Data.Linq.ChangeConflictException