今天在DELPHI中用ADO通过ODBC连MySQL更新数据时遇到这个奇怪的错误:无法为更新定位行。一些值可能已在最后一次读取后已更改。
百思不得其解,于是上网查。有的说是因为没主键,但我这个表是有的;有的说是有缺省值,我检查了一下,所有字段都是没缺省值的;有的说是先INSERT再EDIT导致的,我这就是纯EDIT、POST,没有INSERT,所以也不存在。
又找了半天,终于找到类似情况,有人说如果EDIT修改的数据与原有数据一样,那POST时就会报这个错误。我检查了一下,还真是,我EDIT其实给字段赋的值是跟修改前一样的,如果稍加改动,字段值有不一样,就能正常POST提交了。解决办法只能是给字段赋值前判断一下值是否相同,真够BT的。
问题到此算是解决了,但为啥会这样呢?通过开启ODBC跟踪日志进行分析,我们大概能猜到了原因。下面这段是给所有字段赋相同值的SQL跟踪日志:
BEXE 13f4-1118EXIT SQLExecDirectW with return code 0 (SQL_SUCCESS)
HSTMT 0x0362C568
WCHAR * 0x0B774FC8 [ -3] "UPDATE `test`.`table1` SET `table1ID`=?,`CONTID`=?,`NAME`=?,...`BKWFID`=? WHERE `table1ID`=? AND `CONTID`=? AND ... AND `BKWFID`=?\ 0"
SDWORD -3
BEXE 13f4-1118 EXIT SQLRowCount with return code 0 (SQL_SUCCESS)
HSTMT 0x0362C568
SQLLEN * 0x0018E804 (0)
注意这时SQLRowCount返回结果是0,意思是更新了0行。
下面这个则是赋值有变化的SQL跟踪日志:
BEXE 13f4-1118 EXIT SQLExecDirectW with return code 0 (SQL_SUCCESS)
HSTMT 0x0362C568
WCHAR * 0x0B76FEC8 [ -3] "UPDATE `test`.`table1` SET `table1ID`=?,`CONTID`=?,`NAME`=?,...`BKWFID`=? WHERE `table1ID`=? AND `CONTID`=? AND ... AND `BKWFID`=?\ 0"
SDWORD -3
BEXE 13f4-1118 EXIT SQLRowCount with return code 0 (SQL_SUCCESS)
HSTMT 0x0362C568
SQLLEN * 0x0018E804 (1)
这时SQLRowCount返回结果是1,意思是更新了1行。
两个SQL一模一样,区别只在于前一个SQL执行后记录内容没有变化,而后一个是有变化!然后对于没变化的情况MYSQL就告诉你,你没有UPDATE任何记录,其实你是UPDATE了一条记录,只是UPDATE前后结果一样,跟没有UPDATE的效果相同,于是MYSQL返回了0,于是ADO认为没UPDATE到数据,于是认为是别人把数据修改掉了,于是就报“无法为更新定位行”的错误了。
补充:
后来接着研究,为了验证这个问题,直接用SQL命令更新一条NAME='公告'的记录:
mysql> update table1 set name='公告' where table1id=1;
Query OK, 0 rows affected
Rows matched: 1 Changed: 0 Warnings: 0
mysql> update table1 set name='公告1' where table1id=1;
Query OK, 1 row affected
Rows matched: 1 Changed: 1 Warnings: 0
mysql>
显然是因为相同值时返回的0 rows affected导致了问题。
然后再上网搜索时,发现MYSQL官方有这个问题的说明,只需要修改MYSQL的ODBC连接配置即可解决:
http://dev.mysql.com/doc/connector-odbc/en/connector-odbc-errors.html
Write Conflicts or Row Location Errors
How do I handle Write Conflicts or Row Location errors?
If you see the following errors, select the Return Matching Rows
option in the DSN configuration dialog, or specifyOPTION=2
, as the connection parameter:
Write Conflict. Another user has changed your data. Row cannot be located for updating. Some values may have been changed since it was last read.
于是照着修改了一下ODBC的连接配置:
改完后,重启应用程序,果然一切正常了。