Issue 319: PyODBC with FreeTDS erroneously reports "Previous SQL was not a query" for empty resultset
Status:  New
Owner: ----
Reported by omega.th...@gmail.com, Apr 25, 2013
When FreeTDS is configured to use TDS protocol version 4.1, an empty result set from a SELECT is reported by an error code of SQL_NO_DATA from SQLExecute. This causes Cursor.next to raise an exception, because PyODBC does not query for column information if it sees this result code.

In contrast, if FreeTDS is configured to use protocol version 7.2, an empty result set from a SELECT reports SQL_SUCCESS_WITH_INFO from SQLExecute, albeit with a rowcount of 0. This causes Cursor.next to raise a DoneIteration exception on the first call, as expected.

It seems to me that PyODBC's special case for SQL_NO_DATA on cusor.cpp:814 should be changed so that SQLNumResultCols/PrepareResults/create_name_map are still called (to set cur->colinfos != 0) even if there is no data. DELETE statements and the like will not return any columns, so will continue to raise an the "no data" exception as desired, but SELECTs will return at least one column and so will be correctly presented as empty iterators by PyODBC.
Jun 7, 2013
#1 csmith32@gmail.com
Just ran into this. I have a query that returns multiple resultsets (on MSSQL via FreeTDS), some of which may be empty, and I can't use the order to reliably identify them if they can disappear from the resultset iteration because they were empty. Originally, I planned to just unpack the results into a list of variables but the number of resultsets may not match the number of SELECTs in the query when this happens. I want to push all the queries in one batch to save on network latency.