[freetds] SQLCancel() and error diagnostic: Expecting HY008SQLSTATE
Sebastien FLAESCH
sf at 4js.com
Tue Jan 15 06:26:43 EST 2008
Frediano,
I have just tested my little sample with the HEAD and I get an HY008 SQLSTATE as expected.
But I still have a problem: I do not get this SQLSTATE when using our Genero VM...
Attached the log ... (using default debug flags, tell me what I should set if needed).
...
Some details that may help:
Our VM is a pseudo-code interpretor where we handle user interruption in different ways.
In console / TUI mode:
When a SIGINT is catched, we just set a global indicator which is checked in the p-code interpreter loop.
=> we do not call directly SQLCancel() from the SIGINT handler.
In GUI mode:
We have a proprietary GUI protocol to connect presentation clients to application with sockets.
When the front-end waits for the application to respond (running SQL statement), it can still send a asynchronous event on the socket.
We use non-blocking select() and we detect SIGIO signals if need data is sent by front-ends.
In this can we do also set a global flag if we catch an interruption GUI event, and processed in pcode interpreter loop.
=> we do not call directly SQLCancel() from the SIGIO handler.
I have tested with TUI and GUI mode, in both cases I can interrupt, but SQLSTATE is 00000.
...
Would the TDS driver only set HY008 when SQLCancel() is called during a sighandler?
I guess no, according to the code you just check the TDS return code:
case TDS_CANCELLED:
odbc_errs_add(&stmt->errs, "HY008", NULL);
So I really wonder... I will investigate a bit more.
It's possible that my FreeTDS interface does more ODBC calls than the like sample I have send.
Thanks,
Seb
Sebastien FLAESCH wrote:
> Thanks Frediano.
>
> Will cvs update the HEAD and make some tests.
>
> Seb
>
> ZIGLIO, Frediano, VF-IT wrote:
>>> 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
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS at lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tds.log
Type: text/x-log
Size: 10381 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20080115/f362cdee/attachment.bin
More information about the FreeTDS
mailing list