sybperl-l Archive

From: Jerry Grooms <grooms at uky dot edu>
Subject: Re: DBD::Sybase 1.01 & queries against temp table
Date: Dec 11 2003 7:38PM

Michael Peppler  writes:

     > Indeed - that select into shouldn't generate a result set at
     > all.

     > I'll try to set up a similar query here (using Sybase) to see
     > what sequence I get.

I looked a bit further at the syb_result_types returned on the newly
DBD upgraded platform and results with an older DBD::Sybase version.
Again, my canned scripted query failed with the new DBD/FTDS, but
still ran ok on the non-updated machine.

When running the same script on both platforms, I noticed
differences in the syb_result_types.  This example query "selects
into" a temp table and then selects from those results.  I'm
beginning to think that the temp table is not really the salient
issue; I've since noticed non-temp table queries behaving oddly.

MS-SQL server:

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   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     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) returned in the second query (older DBD/FTDS).

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).

Jerry