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.
6 messages in com.mysql.lists.plusplusRe: Using Result, Query::store, Query...