Skip to Content.
Sympa Menu

freetds - Re: dbsqlexec doesn't cleanup on error

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Mark J. Lilback" <mark AT lilback.com>
  • To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
  • Subject: Re: dbsqlexec doesn't cleanup on error
  • Date: Tue, 26 Jun 2001 13:36:55 -0500


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.




Archive powered by MHonArc 2.6.24.

Top of Page