FreeTDS Development Group

[Jerry Grooms <grooms AT uky.edu>]

Lowden, James K <LowdenJK AT bernstein.com> writes:

     > One change from 0.53 is that FreeTDS no longer identifies
     > itself as an ODBC driver (unless the ODBC driver is used).
     > That affects default column nullability (and other things).
     > I don't see how that could affect anything here, but it's
     > worth keeping in mind.

     > If we could see a TDSDUMP log, that would help.  It's
     > possible, as Frediano says, that DBD::Sybase is opening a
     > second connection.  That would explain the nonexistence of
     > the temp table.

     > It's also possible FreeTDS is falsely reporting busy-ness,
     > inducing DBD::Sybase to create a new connection when it
     > doesn't (as far as the server's concerned) really need to.
     > If that's the case, you've got our full attention, because
     > we'd want that fixed before the release.

I looked a bit further at the syb_result_types returned on the newly
DBD/FTDS 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.  But, it's
not entirely clear (to me) which layer is the reason for the change
I'm seeing.

When running the same query script on both platforms (against the
same database), 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.


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

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

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

Thanks,

Jerry