[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