the call to the stored
procedure was returning an error, that I can only seem to
correct by
setting the CLIENT_MULTI_STATEMENTS when it connects.
Let's investigate that, and see if a cleaner option than extending
connect_to_db() turns up. Surely there's a way to avoid that...
I couldn't really find a clean way to modify the client_flag of the
options struct using the published c api. It will work if you have the
multi-statements and multi-results options set under the proper group in
the options file. I tried creating a multiquery.cnf and using
set_option to specify that as the default options file, but that didn't
really work because the Connection class actually prevents you from
doing this by reseting it back to "my" when connecting. Seeing as
modifying the default options file would ignore the user's my.cnf files,
I didn't really think it was worth it to explore changing the Connection
class to not reset the default options file to read. I guess this
leaves us with a few options:
1) Add some sort of method to Connection that allows you to manipulate
the options struct of the mysql handle directly.
2) Have the user add the "multi-statements" and "multi-results" options
to the "client" group or a new "multiquery" group in their my.cnf.
3) Extending connect_to_db to be able to specify supplied client_flags
4) Having multiquery.cpp connect using it's own function rather than
connect_to_db.
You don't actually have to add it to the repository; you can
say "svn add myfile", then do the diff, and then "svn revert
myfile". But you might not be able to do that as an anonymous user.
That works. I wonder if it wouldn't help future contributors if that
was mentioned in the HACKERS file.
13 messages in com.mysql.lists.plusplusRE: Stored Procedures & Multiple Resu...
.zip