FreeTDS Development Group

[Thompbil18 AT aol.com]

Hey David,

I suspected something like that. 
My rcall is that the update statistics stuff is embedded in a stored 
procedure the server executes. It shouldn't really send you a stored 
procedure return 
status in my view, but I guess we're going to have to live with that.

So what happens is this :

we (freetds) receive the return status message.
we have no way of knowing of course whether this is a valid return status 
that you might want to retrieve or not, so we do what we do with all return 
status messages - we "manufacture" a result set for the return status, and 
inform 
ct-library that there is a return status to fetch.

When you get the singleton row return of zero - that's the return status 
you're seeing.

You then say that you see a cancel being issued, and all the following 
results being discarded. 

This would make sense if the "fetch" logic within DBI::Sybase is either:

a) only catering for one result set from a submitted statement

or

b) assuming that a return status signals the logical end of the returned 
data.

I don't know which is happening - you could try putting two select statements 
that return differently "shaped" result sets into the query you submit, and 
see how your script handles it. If it only outputs the results from the first 
result set, then (a) above is the case....

HTH,

Bill