When using MySQL 5.0 with Pike 7.4 I get an error message (only) when a called stored procedure has an empty resultset. Calling the stored procedure with a MySQL management application does not result in any problems. I get the following message: PROCEDURE {X} can't return a result set in the given context
Now, is this Pike or MySQL? If it's Pike, what am I doing wrong? If it's MySQL, well, any suggestions?
Coen
__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.
The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________
Some googling came up with this page:
http://guyharrison.typepad.com/guy_harrisons_blog/2006/04/mysql_stored_pr.html
So I think what's needed is to specify (["connect_options":0x20000]) as the options mapping when you call Mysql.create. (0x20000 is the value of CLIENT_MULTI_RESULTS, AFAICT.)
According to the MySQL documentation the option 0x20000 activates 'extra safety checks (131072/FLAG_SAFE) next to that, FAFAIK, I do not return multilple results or even execute multiple statements. But when I decided to give this a try anyway, I came across a very, very strange problem (with Roxen & Pike)
When I tried adding the mapping, as proposed, to my code. Roxen does start, but remains unreachable via a webbrowser. But, and this is the strange part. When I change the string literal from "connect_options" to for example "variable", Roxen starts and is available. Isn't this strange?! I know this is the exact cause for the change to occur, since it is truly the only thing that was changes.
What is happening here?
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Some googling came up with this page:
http://guyharrison.typepad.com/guy_harrisons_blog/2006/04/mysql_stored_pr.html
So I think what's needed is to specify (["connect_options":0x20000]) as the options mapping when you call Mysql.create. (0x20000 is the value of CLIENT_MULTI_RESULTS, AFAICT.)
__________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.
The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________
I can't find any "FLAG_SAFE" in my mysql header files, but there is
#define CLIENT_MULTI_RESULTS (1UL << 17) /* Enable/disable multi-results */
What MySQL version are you using? I think this flag is new in MySQL 5.
And I don't see why it comes as a surprise that not specifying any connect_options has the same effect as not specifying any connect_options. Too bad that specifying the connect_options didn't seem to have the desired effect though.
pike-devel@lists.lysator.liu.se