FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

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.  

--jkl