From: Warren Young
Date: August 9 2007 5:37pm
Subject: Re: Using Result, Query::store, Query::store_next and Connection::opt_multi_statements
 with INSERT, UPDATE, DELETE etc.
List-Archive: http://lists.mysql.com/plusplus/6904
Message-Id: <46BB50F4.4020406@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

James Vanns wrote:
> OK, so with the latest version of MySQL++ 2.3.2 and MySQL 5.0.27 I
> don't seem to get the correct return code from Query::success() when
> using multi-statements that don't return a result set. This used to
> work with 2.1 and according to the MySQL page referenced in you
> developer documentation/reference manuals:
> 
> http://dev.mysql.com/doc/mysql/en/c-api-multiple-queries.html

On investigating this, the new way isn't right, but the old way wasn't 
right either.

What's happening is that we weren't doing anything with Query::success_ 
flag if mysql_query() succeeded but the subsequent store operation 
failed.  This isn't always an error, as you've noticed: it can just mean 
that the result set is empty.  But it can also mean out of memory and 
other bad things.

The easy fix is to just remove the "success_ = false" after calls to 
mysql_store_result() and similar in lib/query.cpp.  The proper fix is 
what I will apply to the svn version, and will appear in v3, which 
follows the recommendation on this page:

http://dev.mysql.com/doc/refman/5.1/en/null-mysql-store-result.html

> It also appears the affected_rows()
> sometimes doesn't return the correct value for say, DELETES.

You're going to have a tough time getting me to believe this is a 
MySQL++ bug.  Connection::affected_rows() is the thinnest possible 
wrapper over mysql_affected_rows().  Also, this code hasn't changed 
between 2.1.1 and 2.3.2.

I'm more likely to believe that either a) the C API just works 
differently than you'd like; or b) if there is a bug, it's in the C API.