PyODBC with FreeTDS erroneously reports "Previous SQL was not a query" for empty resultset

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by omega.th...@gmail.com on 25 Apr 2013 at 2:32

[GoogleCodeExporter]

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.

Original comment by csmith32@gmail.com on 8 Jun 2013 at 1:21