FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Christophe Combelles wrote:
> token.c:1920:processing row.  column size is 1
> token.c:1863:tds_get_data: column 12, type 111, varint size 1
> net.c:446:Received header
> 0000 04 01 00 11 00 00 00 00-                        |........|
> 
> net.c:542:Received packet
> 0000 fd 30 00 02 00 d1 04 00-00                      |.0...... .|
> 
> token.c:1920:processing row.  column size is 253

That "fd 30 00" means "end of result set (fd), "results cancelled (30)".  

All I can tell you is the server acknowledged the cancel message, which
should have resulted in ct_cancel() succeeding.  I can't tell if
ct_cancel() returned and nothing happened after that, or if it never
returned.  

Pray  for rain.  I can't commit to looking into this while the weather's
nice.  

It will take some investigation to understand the ct-lib error handling --
there are two kinds, synchronous and asynchronous -- and to develop unit
tests for them.  (ct_cancel doesn't appear in any unit test today.)  Once
they prove out, you can try re-linking your Python module.  If that
doesn't work, we'd have to look at their code.  

If you want to speed the process along, you could try to understand their
cancel processing, and/or try your hand at writing a test case for
ct-cancel().  

Otherwise, thanks for the problem report.  I think it's possible you've
found a bug.  At the very least, you've highlighted the fact that we don't
have a unit test for cancel processing in ct-lib.  

--jkl