Multi result sets in 3.51.12 - patch workaround

Richard Riley <[email protected]>
Newsgroups gmane.comp.db.mysql.odbc
Message-ID <[email protected]>
All,

Using C++ OLE DB -> MyODBC I was observing random connection failures while 
calling stored procedures that return their own result set. I believe this was 
caused by the "extra" emtpy result set that is returned by the server to 
represent the status of the actual CALL (this behaviour is documented in the 
manual).

The MyODBC connector sets the CLIENT_MULTI_RESULTS when connecting to MySQL. As 
per section 22.2.9 of the manual, "If you enable multiple-statement support, you 
should process the results from mysql_query() and mysql_real_query() within a 
loop that checks for more results. This is true even for statements such as DROP 
TABLE that return a result but not a result set. Failure to process the result 
this way may result in a dropped connection to the server."

Any easy workaround is to add these lines to handle.c -

/* Retrive and discard any pending result sets */
while (mysql_next_result(&stmt->dbc->mysql) == 0)
    mysql_free_result(mysql_store_result(&stmt->dbc->mysql));

Obviously this is no good if you genuinely want to return multple sets of data, 
but it's good enough to prevent connection failures caused by the additional 
empty set that results from a stored procedure call.

If this is of help to anyone (any maintainers / developers out there?) then I can 
submit a full patch. In future there is presumably a plan to support multiple 
result sets properly...

Regards

Richard Riley





-- 
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe:    http://lists.mysql.com/[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.