Concurrency error, but is it?
-
- Posts: 38
- Joined: Tue 07 Mar 2006 17:13
Concurrency error, but is it?
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
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
-
- Posts: 38
- Joined: Tue 07 Mar 2006 17:13
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
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
Most possible, that the problem has been fixed in 4.00. Can you reproduce it if not set ConflictOption?Does this sound like a plausible result, or have I simply changed something which is causing another problem I have not found?
We will fill this gap in future.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?
-
- Posts: 38
- Joined: Tue 07 Mar 2006 17:13
-
- Posts: 38
- Joined: Tue 07 Mar 2006 17:13
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.
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.