[freetds] Instances where TDS_RETURNSTATUS_TOKEN is returned
Ryan Barber
rbarber at dargal.com
Tue Feb 17 09:53:29 EST 2004
Thanks James, This makes sense now..
-Ryan
James K. Lowden wrote:
>On Mon, 16 Feb 2004, Ryan Barber <rbarber at dargal.com> wrote:
>
>
>>James K. Lowden wrote:
>>
>>
>>>On Mon, 16 Feb 2004, Ryan Barber <rbarber at dargal.com> wrote:
>>>
>>>
>>>
>>>>Oddly enuf, the only situation where this happens is when selecting
>>>>
>>>>
>>>from>a temporary table, and only when a where clause is used. Not a
>>>complex>where query either, eg:
>>>
>>>
>>>>SELECT * FROM #TEMPTABLE WHERE ID > 32;
>>>> vs.
>>>>SELECT * FROM #TEMPTABLE;
>>>>
>>>>Granted, this is probably only a quirk with our version of MSSQL, but
>>>>
>>>>
>>>we>still need a way to suppress TDS_RETURNSTATUS_TOKEN being returned
>>>as a>result set to DBD::Sybase.
>>>
>>>
>>>
>>SQL Server Enterprise Edition
>>8.00.760 (SP3)
>>Microsoft Windows NT - 5.0 (2195)
>>
>>Reviewing tdsdump logs from .53, when passed a RETURNSTATUS token,
>>freetds would just step over it.
>>
>>
>
>Right, that's what I thought.
>
>
>
>>I'll look in DBD::Sybase, see if I can find where this result_type is
>>being read.
>>
>>
>
>DBD::Sybase should call ct_fetch(), which should set result_type to
>CS_STATUS_RESULT. "perldoc DBD::Sybase" discusses the status result row,
>and advises you to consult $sth->{syb_result_type} to determine the result
>type.
>
>Thank you for the logs. I told you I don't see why the server would send
>a RETURNSTATUS packet, but I'm going to take that back, or at least
>rephrase. In the many TDS logs I've read, I've often seen seemingly
>extraneous DONEINPROC tokens. The server is apparently executing some
>stored procedure behind the scenes, nothing the user requested explicitly.
> This has caused us some consternation wrt to triggers and counting rows.
>So, I have to say if you're seeing "extra" return statuses, it's probably
>"right" insofar as ct-lib is offering up what the server sent, expected or
>no.
>
>It not clear what if anything should be done. There's no ctlib-over-TDS8
>specification, no definition of how ct-lib *should* work with Microsoft
>servers. It's also far from clear how our ct-lib is supposed to
>distinguish unanticipated return statuses from "real" ones. Probably the
>best answer lies in the application: code for a return status even if it's
>not expected, and toss it out if it's meaningless.
>
>
>
>>Also, I never noticed the 'Troublesome bytes:' before, but I don't
>>belive it relates to this problem.
>>
>>
>
>tds_put_string() is a little broken in CVS. Your select statement is 177
>characters, 128 of which can be converted at a time (using its local
>buffer) into UCS-2 for the server. When the whole 177 are passed to
>tds_iconv(), it reports E2BIG (error 7) at the 128th byte, leaving 49
>"troublesome bytes". It logs the message, then goes on to convert and
>transmit them.
>
>Sigh. I wonder if we'll ever get this function right.
>
>
>
More information about the FreeTDS
mailing list