 | | | Using Result, Query::store, Query::store_next and Connection::opt_multi_stat | Using Result, Query::store, Query::store_next and Connection::opt_multi_stat 2007-08-09 - By Warren Young
Back
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.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsub=mysql@(protected)
|
|
|