freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
Re: PHP: losing client/server sync after error (cvs, Sybase ASA)
- From: <lbayuk AT mindspring.com>
- To: freetds AT franklin.oit.unc.edu
- Subject: Re: PHP: losing client/server sync after error (cvs, Sybase ASA)
- Date: Mon, 2 Sep 2002 21:27:30 -0400 (EDT)
James K. Lowden wrote:
> According to CVS tds_process_cancel() changed, just as you say, in
> revision 1.26 of token.c. It was part of the "tight loop" patch. Squish
> one bug, find another? OTOH, token.c has seen a lot of work; something
> else may be happening.
>
> That "0f" is a "TDS_BUF_NORMAL" response (p. 195 in the document below).
> The 0x03 after it is the status byte, indicating TDS_BUFSTAT_EOM (bit 0,
> last buffer in a response) and TDS_BUFSTAT_ATTNACK (bit 1,
> acknowledgment). That's the expected response to a cancel request.
>
> tds.h doesn't define a token for 0x0f, so I think our cancel protocol
> processing isn't interpreting it correctly.
>
> The real question, as far as I can tell, is not what the first response is
> (that looks fine according to their doc), but how to know to expect more
> incoming data on an "idle" link.
>
> I know almost nothing about the TDS protocol proper, so I'm not going to
> be very helpful in telling you what to do. In particular, I don't know
> how tds_process_cancel() can know that it's going to receive two (or
> more?) responses. According to the documentation, what you say you're
> seeing can't happen. I've attached the relevant part from page 20, in
> case you don't want to download the whole thing. HTH.
The documentation isn't 100% clear to me, as elsewhere it says after
cancel the client reads and discards "until attention acknowledge", which
might refer to the TDS_DONE_ATTN flag in the Result Set Done packet. Maybe.
I wonder how other TDS-5-speaking databases reply to ct_cancel().
Can anyone look at a socket trace (not FreeTDS dump file, which does
not show the packet) from PHP talking to Sybase ASE 11 or 12,
for example? I'm really curious what they do in this case. Just send it
one or two bad queries and see what happens, something like:
$conn = sybase_connect("servername", "username", "password");
sybase_query("insert into nosuchtable1 values (1)", $conn);
sybase_query("insert into nosuchtable2 values (1)", $conn);
Also note that this doesn't seem to be easy to work around, because
tds_read_packet() can't really handle a header-only packet like
I'm seeing. It returns 0, which is the same as an error return.
-
Re: PHP: losing client/server sync after error (cvs, Sybase ASA),
James K . Lowden, 09/01/2002
- <Possible follow-up(s)>
- Re: PHP: losing client/server sync after error (cvs, Sybase ASA), Brian Bruns, 09/02/2002
- Re: PHP: losing client/server sync after error (cvs, Sybase ASA), lbayuk, 09/02/2002
Archive powered by MHonArc 2.6.24.