FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Hi everyone back in town, vacation was great.

empty_res_hack is there to deal with the fact that the TDS protocol and
the dblib API are a bit disimilar in dealing with results.

When the TDS layer finishes reading results it returns TDS_NO_MORE_RESULTS
to the cli (dblib in this case).  Problem is if you call dbresults() on a
query that produced no results the first invocation is supposed to return 
SUCCEED, the second returns NO_MORE_RESULTS.  Some application (early sqsh
versions or php or something) relied on this particular behaviour and thus
empty_res_hack was created as a book keeping mechanism to track how many
times you've called dbresults so it can return the right value on each
invocation.

Anyway, on to your problem! The fact that this is still set should be
meaningless (it gets reset with the next call to dbsqlexec/dbsqlsend). 

In dbsqlok() the logic in the first half doesn't seem to match the logic
at the end of the procedure, specifically 'rc' is never equal to TDS_ERROR
and thus the cleanup code never runs.  However, given the structure of the
code above it, the cleanup code is redundant anyway. 

Actually, I'm finding it difficult to see where empty_res_hack would be
set to 1 anway if you are not calling dbresults() yourself.  Can you post
a section of the dblib program demoing this problem.

Brian

On Fri, 22 Jun 2001, Mark J. Lilback wrote:

> If dbsqlexec returns an error, it appears you have to call dbresults 
> or the next results will be in an incorrect state.
> 
> According to the OpenClient DB/Library C Reference (10.0 release), 
> this is not the expected behavior -- calling dbresults is only 
> required if dbsqlexec returns SUCCESS.
> 
> I'm seeing this by sending the query "select id,name from foo where 
> id < 3," twice and looking at the values in the debugger.
> 
> Can someone else confirm this behavior?
> 
> I'm seeing different tds->in_pos values, even though the query 
> returns the same packet from the server. Also, I end up with 
> dbproc->empty_res_hack set to 1.
> 
> What is dbproc->empty_res_hack for, anyway? It doesn't sound good, 
> especially since I'm seeing it set when I have problems.
> 
> Thanks.
> 
>