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
• Status: Verified
• Category: MySQL Server: C API (client library)
• Severity: S4 (Feature request)
• Version: all
• OS: Any (all)
• CPU Architecture: Any

[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.