Re: Using Result, Query::store, Query::store_next and Connection::opt_multi_statements with INSERT, UPDATE, DELETE etc.

[James Vanns]

I don't think I suggested it was a major 'problem'. Just a minor inconvenience ;) 

With regards to the Query::success thing, naturally I use try {} catch {} blocks for
MySQL++ exceptions but I can't check the return status of a Result object - cos there
isn't one! Would it be worth using Query::error().empty () within that loop? I need to
know if a single statement within that multi-statement 'store' operation (or store_next)
failed.

As far as the 'affected rows' thing is concerned I'm dead serious. Both with this version
and the one I used previous (2.1) I can do this:

query << "UPDATE blah;DELETE foo;INSERT whatever;SELECT something";

run the algorithm previously posted and have 0 rows affected returned by
Connection::affected_rows(). Running the exact same statements through a mysql shell
against the same result set - it returns 2 rows affected for the update, 1 for delete
etc.

Sometimes it even manages to return UINT_MAX ;) This is on an Intel 32-bit Fedora 6
machine. The documentation suggests it returns a type of 'my_ulonglong'. This is simply
an unsigned long long? Which, on my machine would be a ULONG_MAX anyway.

Reading

http://dev.mysql.com/doc/refman/5.0/en/mysql-affected-rows.html

is confusing - it says a -1 can be returned even though the type is an unsigned integer!
Granted this particular caveat isn't the fault of MySQL++!

Jim

----- Original Message -----
From: "Warren Young" <mysqlpp@stripped>
To: "MySQL++ Mailing List" <plusplus@stripped>
Sent: 09 August 2007 19:20:07 o'clock (GMT) Europe/London
Subject: Re: Using Result, Query::store, Query::store_next and
Connection::opt_multi_statements with INSERT, UPDATE, DELETE etc.

James Vanns wrote:
> 
> Has something this major changed? 

I also want to point out that this only affects the intersection of two 
minorities:

a. Those that call Query::store() or use() with queries that can return 
empty results instead of exec{ute}(), the proper call when you know in 
advance that the result set will be empty.

b. Those that pay attention to Query::success() instead of method return 
values or exceptions to detect errors.

This is why you're the first to report this, even though it happened in 
v2.2.0, released over 7 months ago.

I am not saying you are wrong to report this, or wrong to write your 
code in such a way that it falls into that intersection of two 
minorities class, or that there is no bug.  But let's keep it in 
perspective, shall we?  This is not a "major" problem.

-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    http://lists.mysql.com/plusplus?unsub=1



-- 
James Vanns
Systems Programmer
Framestore CFC Ltd.