FreeTDS Development Group

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

On Wed, 1 Jan 2003 09:00:25 -0700, "Chris McDaniel"
<Chris.McDaniel AT telus.com> wrote:
> 
> I got a fresh cvs checkout, recompiled and tried it again. 
> Unfortunately I cannot use tdsver 7.0 as it is an MS SQL 6.5 server and
> I get login failure if I try higher tds versions (and a core dump).  As
> before, I still get no results back from the proc.  

Chris:  Does "no results back from the proc" mean no result set (no data)
or no return code?

Frediano:  Our return code processing is broken in ct-lib; it may be
affecting ODBC, too.    

I thought we needed a unittest for return code processing, so I modified
src/ctlib/unittests/t0002.c.  It calls "exec sp_who" and prints the result
set and the return code status (which of course should always be zero for
sp_who).  

I'm no ct-lib maven; I just tried to follow instructions and rely on the
rest of the unittests for examples.  AFAICT, I've coded it correctly, but
ct_results() fails to retreive the return code. 
tds_process_result_tokens() does not place the return code in the buffer
provided by ct_bind(), so the return code cannot be retrieved with
ct_fetch().  

The sequence of events:

1.  sp_who result set arrives and is processed normally (7 columns).
2.  ct_results() is called again.  
3.  TDS_RETURNSTATUS_TOKEN (0x79) arrives.  
4.  tds_process_result_tokens() records the status in the TDSSOCKET and
returns a type 4043.  It should do more: set the column count and create
the row.  
5.  ct_results() returns CS_STATUS_RESULT, indicating a status row is
available.  
6.  t0002.c calls ct_describe(), which says there are (still) 7 columns, a
lie.  
7.  t0002.c calls ct_fetch().  It doesn't know it's supposed to return a
status row.  It calls tds_process_row_tokens() and returns CS_END_DATA
without returning any rows.  

Nota Bene.  Other recent logs have shown TDS_RETURNSTATUS_TOKEN markers
arriving from a TDS 8.0 server when *no* stored procedure was executed. 
Return code processing will have to tolerate that.  We'll have to set up
the rows for retrieval and discard them if they're not requested.  

HTH.

--jkl