FreeTDS Development Group

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

> 
> Hello James,
> 
> First thanks a lot for taking the time to explain the internals.
> 
> Resources (just to compare):
> 
> With DB2 CLI, they don't talk about SIGINT, but rather 
> multi-threaded applications where a second thread issues SQLCancel().
> 
> http://webdocs.caspur.it/ibm/db2/8.1/doc/htmlcd/en_US/ad/r0000567.htm
> 
> With Oracle OCI, they talk about Control-C:
> 
> http://download.oracle.com/docs/cd/B14117_01/appdev.101/b10779
> /oci02bas.htm#462655
> 
> Of course, nothing about SIGINT on MSDN:
> 
> http://msdn2.microsoft.com/en-us/library/ms714112.aspx
> 
> ...
> 
> I can probably use any solution you will provide to handle 
> SQL interruption.
> But I believe there is a good chance to have other ODBC 
> programmers handle SQL interruption with a SIGINT + 
> SQLCancel() as I did.
> Therefore, you better choose the second "robust" solution.
> 

Currently CVS HEAD seems to handle all situations correctly.

> Note BTW that several SIGINT signals can be generated 
> successively: Frustrated users keeping CONTROL-C pressed down ;-).
> => Many SQLCancel() calls ...
> 

First send cancel than it wait for cancel handling by server. So others
SQLCancel just do nothing.

> I wonder however why the TDS protocol does not yet specify 
> how to handle query interruption.
> To me this should be part of the protocol definition (= you 
> should not have to choose between different solutions)
> 
> ...
> 

??? it calls cancellation.

> Looks like you have to do tricky things (cleaning up the 
> connection) to handle this... right?
> 
> Just a remark:
> 
> Maybe SQLCancel() (query interruption in TDS) is only 
> supported since SQL Server since version 2005?
> 
> I just remember that we started to support SQL interruption 
> with SQL Server native ODBC drivers since 2005 only.
> Quite sure it was not working before that version... but must 
> double check.
> 

cancellation is supported even by protocol 4.2.

> I can only suggest to try my little SQLCancel() example with 
> SQL Server 2005 and sniff the protocol.

See odbc cancel test. I use alarm to emulate ctrl-c

> But it must be adapted to catch console events to trap CTRL-C 
> (does not with with SIGINT of course)
> I will try to adapt the sample and send it back.
> 
> Thanks!
> Seb
> 

The bad thing... it seems that if test is executed using unixODBC it
fails. Our SQLCancel is not called (that is you call SQLCancel and
unixODBC do not call driver one... it hangs). I use unixODBC 2.2.11,
I'll test with 2.2.12


freddy77