Every now and then, after a cursor.execute(query,params) I get this number reported by cursor.rowcount. At the same time, cursor.description == None. Issuing the same query in mysql client works find. That makes me wonder if this is a bug in MySQLdb or if there is some settings that I can adjust.
This is a debian sarge installation. Kernel is 2.6.8, mysql-server-4.1_4.1.8a-1_i386, python2.3-mysqldb_1.1.6-1_i386, python2.3-egenix-mxdatetime_2.0.5-2_i386
(*all are latest versions available in debian sarge)
Any suggestion is much appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also see PEP-249: Values returned by the execute() method are undefined. Don't use them. Use the rowcount attribute instead. This will always be -1 on SSCursor however as it cannot be determined in the MySQL API.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Every now and then, after a cursor.execute(query,params) I get this number reported by cursor.rowcount. At the same time, cursor.description == None. Issuing the same query in mysql client works find. That makes me wonder if this is a bug in MySQLdb or if there is some settings that I can adjust.
This is a debian sarge installation. Kernel is 2.6.8, mysql-server-4.1_4.1.8a-1_i386, python2.3-mysqldb_1.1.6-1_i386, python2.3-egenix-mxdatetime_2.0.5-2_i386
(*all are latest versions available in debian sarge)
Any suggestion is much appreciated.
Same problem here !
18446744073709551615 rows found as result of the execute() method
workaround : change "SSCursors" by "Cursors" does the trick with me.
You cannot use the rowcount with the SSCursor as this is impossible to determine with the MySQL API.
Also see PEP-249: Values returned by the execute() method are undefined. Don't use them. Use the rowcount attribute instead. This will always be -1 on SSCursor however as it cannot be determined in the MySQL API.