Skip to Content.
Sympa Menu

freetds - Re: [freetds] DBD::Sybase 1.01 & FTDS 0.62-dev & temp tables

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] DBD::Sybase 1.01 & FTDS 0.62-dev & temp tables
  • Date: Wed, 17 Dec 2003 23:48:03 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page