FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: David Keith
> Sent: Tuesday, July 27, 2004 12:43 PM
> 
> 10:48:00.226794 processing row tokens.  marker is  ff(DONEINPROC)
> 10:48:00.226837 tds_process_end: more_results = 1
>                 was_cancelled = 0
>                 error = 0
>                 done_count_valid = 1
> 10:48:00.226875                  rows_affected = 2
> SQLFetch: NO_DATA_FOUND

Thus endeth a fetch.  

> Sending packet @ 10:48:00.227327
> 0000 06 01 00 08 00 00 01 00-                        |........|
                ^^ 8-byte language packet

New query sent ... oops!  Where's the rest of the packet?  

> 10:48:00.227417 tds_process_default_tokens() marker is 
> 79(RETURNSTATUS)
> 10:48:00.227453 tds_process_default_tokens: return status is 0
> 10:48:00.227480 tds_process_default_tokens() marker is fe(DONEPROC)
> 10:48:00.227508 tds_process_end: more_results = 0
>                 was_cancelled = 0
>                 error = 0
>                 done_count_valid = 0
> 10:48:00.227591 tds_process_end() state set to 
> TDS_IDLE

More stuff being received.  Different session?  We can't tell.  

> Received header @ 10:48:00.227637
> 0000 04 01 00 11 00 36 01 00-                        |.....6..|
> 
> 
> Received packet @ 10:48:00.227690
> 0000 fd 20 00 fd 00 00 00 00-00                      |. ...... .|
> 
> 
> 10:48:00.227725 tds_process_end: more_results = 0
>                 was_cancelled = 1
>                 error = 0
>                 done_count_valid = 0
> 10:48:00.227761 tds_process_end() state set to
> TDS_IDLEodbc:SQLColAttributes: fDescType is 1011
> odbc:SQLColAttributes: fDescType is 1012
> odbc:SQLColAttributes: fDescType is 1011
...
> 10:48:05.807666 setting column 3 NULL bit

We're receiving a (cancelled?) result set, but where were columns 1 and
2?  

> tds_submit_query(): state is PENDING
> 10:48:05.807750 tds_client_msg: #20019: "Attempt to initiate a new SQL
> Server operation with results pending.".  Connection state is now 1.

and the ODBC driver finally throws in the towel.  

+++

Things don't look good, David, although we can't be sure because there's
no session ID in the log.  (That's a known problem.)  The TDS protocol
doesn't keep one, either, so it's not present in the data.  

Was this log created with "append dump = yes"?  By redirecting stderr?
Neither?  

If neither, then the log has but one session and there's definitely a
problem with client threads sharing a single session.  Otherwise, if
either of the other two methods were used, multiple sessions are
interleaved in the log.  

Nevertheless, if the log is to be believed, a query was interrupted
during transmission.  Something else arrived meanwhile.  If those things
were happening on one session, the application is definitely borked.  If
not, well, it'll take some intensive debugging and maybe better logging
to sort it out.  

With repect to the thread/fiber issue, I think we're talking apples and
oranges.  I'm talking about client threads.  How the server is set up
doesn't affect the absolute truth about the TDS protocol: results must
be either read entirely or cancelled before issuing the next query.  

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to 
inform and update our clients, prospects and consultants of developments 
relating to our services and products, would not like to receive further 
e-mail correspondence from the sender, please "reply" to the sender 
indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, 
NY 10105.