[freetds] SQLCancel() and error diagnostic: Expecting HY008SQLSTATE
Sebastien FLAESCH
sf at 4js.com
Tue Jan 15 07:24:24 EST 2008
Ok, I could reproduce the new problem:
I don't get SQLSTATE=HY008 when using server-side cursors...
Try attached sample to reproduce.
Seb
Sebastien FLAESCH wrote:
> 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
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: odbctest32.c
Url: http://lists.ibiblio.org/pipermail/freetds/attachments/20080115/a683eddb/attachment.c
More information about the FreeTDS
mailing list