Bug #14547 mysql_affected_rows() and mysql_info() client calls not made upon error
Submitted: 1 Nov 2005 19:08 Modified: 18 Nov 2005 16:19
Reporter: Matthew Lord Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: C API (client library) Severity:S4 (Feature request)
Version:all OS:Any (all)
Assigned to: CPU Architecture:Any
Triage: D5 (Feature request)

[1 Nov 2005 19:08] Matthew Lord
Description:
This can really only affect non transactional storage engines that allow multi row inserts, updates and deletes.  This was tested with MyISAM only.

If you do a bulk insert into a myisam table and one of the records fails for some reason, say duplicate key error, you cannot tell how many rows were created successfully.

We are not incrementing the MYSQL->last_used_con->affected_rows structure variable with
each successful row that's affected but rather setting this value along with the mysql_info 
structures when the SQL statement finishes w/o error.  This makes sense for transactional
engines but not for MyISAM because X rows were still affected.

How to repeat:
use test;
create table affected_test (id int not null auto_increment primary key);
insert into affected_test values (3);
insert into affected_test values (1), (2), (3);

You can see that you don't get the mysql_info() information here.

You can also use a simple C test app to test mysql_affected_rows.  I will attach the one I used to the bug report.

Suggested fix:
For myisam we should increment the affected rows structure variable after each successful row
write and still set the mysql_info() information, at least when the query was a batch write query.
[1 Nov 2005 19:10] Matthew Lord
c app to show that affected_rows returns -1 when it should return 2 in this case.

Attachment: test.c (application/octet-stream, text), 1.06 KiB.