Concurrency error, but is it?

[email protected] · Post by **[email protected]** » Thu 09 Aug 2007 20:50

In my application I issue an Update command on a MySQLDataTable. The control attempts to update 8 rows. The first 7 process without error. The 8th comes back with a DBConcurrencyError: the Update Command affected 0 of the expected 1 rows.

When I examine the command using the DBMonitor I see what I believe to be correct SQL, along with valid params being passed. A debug walkthrough indicates that none of my rows has errors. And in the Error tab of the DBmonitor it indicates "Completed successfully". Yet the DBMonitor agrees that "-- 0 row(s) affected. "

It is possible in my application that none of my fields have actually changed, but that I'm tripping the RowState to modified in the manner in which I'm assigning values (since the assigned values may be the same as the original across all fields).

Is it possible that in this case the update command would return 0 rows affected? If so, how do I prevent the Update command from exiting and throwing this exception?

Or am I misunderstanding where it says "command complete" in the errors tab of the DBMonitor? If indeed a valid error is being thrown, can you recommend some manner in which I can dig in to understand what is causing this error so I can rectify it?

FYI, VB 2005, CoreLab 3.55.20, MySQL 5.0

Thanks,

John

Alexey · Post by **Alexey** » Fri 10 Aug 2007 07:36

Please send me your project, including the definition of your own database objects.

[email protected] · Post by **[email protected]** » Mon 13 Aug 2007 13:27

Alexey,

I've updated to CRLab MySQLDirect 4.00.13. After the update, I set the mysqldatatable1.conflictoption = conflictoption.overwritechanges. Now I don't get this error.

Does this sound like a plausible result, or have I simply changed something which is causing another problem I have not found? When I try to search the CRLab help documentation on "ConflictOption" the topic doesn't exist in the documentation index. Am I doing something wrong?

Thanks,

John

Alexey · Post by **Alexey** » Mon 13 Aug 2007 14:28

Does this sound like a plausible result, or have I simply changed something which is causing another problem I have not found?

Most possible, that the problem has been fixed in 4.00. Can you reproduce it if not set ConflictOption?

When I try to search the CRLab help documentation on "ConflictOption" the topic doesn't exist in the documentation index. Am I doing something wrong?

We will fill this gap in future.

[email protected] · Post by **[email protected]** » Mon 13 Aug 2007 15:02

Alexey,

When I comment out the .ConflictOption setting, it creates the exact same error as with 3.50. I went looking for this because there was a thread in the actual MySQL.com forums which suggested exactly this fix to the connector toolset.

Thanks,

John

Alexey · Post by **Alexey** » Wed 15 Aug 2007 11:15

Could you find out what is the update command when the error occurs? (Use DBMonitor and MySqlMonitor component.)

[email protected] · Post by **[email protected]** » Wed 15 Aug 2007 18:25

I've just sent the DBMonitor logs to [email protected], per your request...

John

Alexey · Post by **Alexey** » Wed 22 Aug 2007 09:22

We have analyzed the project you have sent me.
Such problems commonly occur when the table has fileds of type double or float. But your table doesn't have such fields.
Unfortunately, MySQLDirect .NET 3.55 doesn't have functionality to resolve the problem.
As a workaround you should create update command in design-time with WHERE clause having only the primary key. Setting ConflictOption to OverwriteChanges should make the same, actually.