FreeTDS Development Group

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

"Lowden, James K" <LowdenJK AT bernstein.com> wrote:
> What is the difference between tds_socket::current_results and
> tds_socket::res_info?  They're both TDSRESULTINFO structures.   Why two?

(I still don't understand why, but that turns out not to be important to
honoring EED packets.)

tds_process_msg() in src/tds/token.c discarded messages whose message
number was zero.  In db-lib, EED packets are routed to the client's
installed message handler, with a message number of zero.  Because
tds_process_msg() discarded them, db-lib never got them.  

I removed the "if (msg.msg_number > 0)" test.  I don't know what effect
that will have on the other libraries yet.  

The problem behind the problem: db-lib clients will attempt to process a
result set whenever an EED packet arrives, using the previous result set's
metadata.  This can lead to bad things.  

The reason?  

        dbresults() calls 
        tds_process_result_tokens() calls
        tds_process_default_tokens() calls 
        tds_process_msg()

which winds up fetching the EED packet.  tds_process_msg() returns
TDS_SUCCEED, and the return code is propogated all the way back to the
application.  The application interprets that as, um, success, and
attempts to fetch a row.  It does not often find what it's looking for.  

I'm too tired now to design a good solution.  The token-reading code has
always seemed clumsy to me.  I don't know if there will ever be results to
process once tds_process_result_tokens() calls
tds_process_default_tokens().  I would guess it should always return
TDS_NO_MORE_RESULTS.  

This looks like a serious bug to me.  I'm hoping we can fix it for the
release.  

--jkl