FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

crawford charles wrote:
> One more question, if your would be so kind:
> what does it mean when a RESULT (0x81) response
> token has a length of -1 (0xFFFF).  This is in
> response to a sp_cursor RPC(core id == 1).  I infer
> that it may mean "refer to previous RESULT", or
> perhaps some default, but it is not immediately
> obvious.

I don't think it's possible.  Cf. src/tds/net.c::tds_read_packet():

        if ((len = goodread(tds, header, sizeof(header))) < (int) 
sizeof(header))
{
...
                return -1;
        }
        tdsdump_dump_buf(TDS_DBG_NETWORK, "Received header", header,
sizeof(header));
...
        /* Convert our packet length from network to host byte order */
        len = ((((unsigned int) header[2]) << 8) | header[3]) - 8;
...
        /* Now get exactly how many bytes the server told us to get */
        have = 0;
        while (have < len) {
                int nbytes = goodread(tds, tds->in_buf + have, len - have);

If we got a header length of -1, we'd never read the packet, because have
== 0 && len == -1, ergo have > len.  You'd have to show me a TDSDUMP log
and a reproducible case to convince me otherwise.  

That endian flopping, above, is weird.  I don't know why it works on Suns,
and I wonder if we shouldn't use ntohs(3) or somesuch.  

> Thank you again for all your help, and for FreeTDS.

You're welcome, of course.  I would like to know, though, what you're
doing, if you'd be good enough to say.  The code's yours to use, as you
know, absolutely.  But when I take the time to answer (or at least try to)
protocol questions, I like to have some understanding of the goal.  I help
people out of partially enlightened beneficence: I hope that what they
learn could benefit the project.  I'd also be interested if someone
intends a different implementation, such as jTDS.  

Freddy asked the same question on March 13.  I didn't notice an answer;
perhaps I missed it.  

Regards, 

--jkl