FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> 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)".  
> 

Mumble mumble... it seems that client part is still expecting row data
while server send cancel acknowledge... it would be helpful to see
previous packet header. Perhaps server stop sending row informations
just sending an empty packet with last flag set to 1 ??

> 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.  
> 

Last week the sun was very hot and I was cooking myself on holiday :)

> 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.  
> 

freddy77