FreeTDS Development Group

["Mark J. Lilback" <mark AT lilback.com>]

At 10:18 PM -0400 6/25/01, Brian Bruns wrote:
> 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.


I'm calling dbcmd to fill the buffer, and then dbsqlexec to send the 
query. dbsqlexec is not returning TDS_SUCCEED, and it is not cleaning 
up after itself unless I call dbresults, which I shouldn't have to do 
if an error was returned. Here's the code I'm using:

        err = dbsqlexec(myData->dbproc);
        if (err != TDS_SUCCEED) {
//Gross fix for bug in freetds. Hopefully will fix there and strip out of 
here.
                dbresults(myData->dbproc);
                goto ERROR;
        }

Without the dbresults call in the error handler, the next query 
executed would return TDS_SUCCEED even though the exact same error 
messages was returned from the server, and empty_res_hack is set to 1.

I was going to work out a command line program I can use on Mac OS X 
to duplicate these problems, since my Mac OS source code wouldn't be 
usable for anyone else.


> 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.
> >

--

__________________________________________________________________________
                                         "The best assumption to have
Mark J. Lilback                           is that any commonly held
<mark AT lilback.com>                        belief is wrong." -- Ken Olsen,
http://www.lilback.com/                   founder, Digital Equip. Corp.