FreeTDS Development Group

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

On Tue, 16 Dec 2003, Jerry Grooms <grooms AT uky.edu> wrote:
> Example/host 1; Query XYZ:
> 1.01 DBD:Sybase & FreeTDS 0.62
> 
> syb_result_type: 4043   (CS_STATUS_RESULT returned with empty row -
> seems new?) syb_result_type: 4040   date ok, etc
> syb_result_type: 4040
> syb_result_type: 4040
> ...
> 
> Example/host 2; Query XYZ:
> 0.95 DBD:Sybase & FreeTDS 0.53
> 
> syb_result_type: 4     data ok, etc
> syb_result_type: 4
> syb_result_type: 4
> syb_result_type: 4
> ....
> 
> I'm unclear why the second query result types are (4) and not
> (4040).  But, something relevant seems to be the absence of the
> (4043) result set returned in the second example (older DBD/FTDS).

A lot has changed in FreeTDS since 0.53.  0.61 had some broken empty
result set handling in ct-lib, but that should be OK since early December.
 Don't be surprised to find behavioral differences.  We consider them to
be enhancements, most of the time.  

For instance, 0.53 discarded many packets, whereas 0.62 handles almost
every one.  

> So, my revised work-around is to check for and skip over the 4043
> return (emtpy row set).  I'm not sure if this is the best approach
> or not, but it gets the query working again (while checking
> syb_more_results).

I'm keen on making your workaround unnecessary, if we can figure out
what's wrong.  

> Should I be able to discern the syb_result_types from a TDSDUMP file
> or is that a DBD only issue?

In a modern TDSDUMP log, you'll find lines like:

23:14:39.006069 ct_results() process_result_tokens returned 1 (type 4052) 

It's very much a ct-lib thing that is reflected in DBD::Sybase.  The full
set of ct_result types can be found in include/cspublic.h:

/* result_types */
#define CS_COMPUTE_RESULT       TDS_COMPUTE_RESULT
#define CS_CURSOR_RESULT        4041
#define CS_PARAM_RESULT         TDS_PARAM_RESULT
#define CS_ROW_RESULT           TDS_ROW_RESULT
#define CS_STATUS_RESULT        TDS_STATUS_RESULT
#define CS_COMPUTEFMT_RESULT    TDS_COMPUTEFMT_RESULT
#define CS_ROWFMT_RESULT        TDS_ROWFMT_RESULT
#define CS_MSG_RESULT           TDS_MSG_RESULT
#define CS_DESCRIBE_RESULT      TDS_DESCRIBE_RESULT

The "TDS" types are in include/tds.h, especially:

#define TDS_ROW_RESULT        4040
#define TDS_PARAM_RESULT      4042
#define TDS_STATUS_RESULT     4043

These are in turn derived from protocol-level information; the bloody
details can be found in src/tds/token.c::tds_process_result_tokens.  

>From the above, we know that your 4043 result is a CS_STATUS_RESULT
result, a "single row containing a single status", according to Sybase. 
And, yep, that's something 0.53 didn't handle, IIRC.  This area saw a lot
of effort in March or so this year, when we worked on rpc stuff.  

If the result set is truly empty, then perhaps we're percolating up
something bogus.  Can you cook up a simple test case?  

--jkl