There are also fetchone calls commented out in test_sprocs.py -- I think these were commented out because of failures due to the same issue -- this should be checked and maybe these lines can be put back.

Hmmm, fix is not that easy. My fix worked with FreeTDS 0.82 but it causes some undesirable behavior with FreeTDS 0.91.

The fix I alluded to above is 6db0897

I mucked around and the first thing I came up with was:

6db0897

which is simply just calling nextset() in callproc after executing the procedure.

At first, I thought this solved things and perhaps it's a step in the right direction. Before adding this line, I was getting an exception ("Statement not executed or executed statement has no resultset") when trying to fetch rows after calling callproc. After adding this line, the exception went away and I got rows back and IIRC it was doing the right thing if the stored proc returned one resultset with rows. However, if the stored proc returned two resultsets where the first had no rows, then it would skip over the 0 row resultset and go straight to the second resultset (and executing a "EXEC storedproc" query didn't do this). I have not been able to find a way to not have the exception and also not skip over a blank resultset. I've been testing my using the script at https://gist.github.com/msabramo/6747703 -- which compares the execute and callproc ways of running the stored proc and does it for both MySQLdb and pymssql. MySQLdb seems to have the desirable behavior here where execute and callproc are always consistent -- I haven't been able to achieve this with pymssql.