[freetds] ODBC - binary, row count and compatibility
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Tue Mar 9 09:57:21 EST 2004
> -----Original Message-----
> From: freetds-bounces at lists.ibiblio.org
> [mailto:freetds-bounces at lists.ibiblio.org] On Behalf Of James
> K. Lowden
> Sent: martedì 9 marzo 2004 15.44
> To: FreeTDS Development Group
> Subject: Re: [freetds] ODBC - binary, row count and compatibility
> On Tue, 9 Mar 2004, "ZIGLIO, Frediano, VF-IT"
> <Frediano.Ziglio at vodafone.com> wrote:
> > > CREATE PROCEDURE testinsert @value INT AS
> > > INSERT INTO TestTransaction VALUES ( @value )
> > > SELECT * FROM TestTransaction
> > > select @value / (@value - @value)
> > > I'm still not sure how to go about fixing this.
> > :(( another issue to fix.... SQLEndTran calls _SQLFreeStmt(CLOSE) if
> > state is PENDING, _SQLFreeStmt send a cancel however I
> don't think this
> > is correct, perhaps _SQLFreeStmt should just discard
> results from server
> > (some tests needed).
> You don't seem to be thinking about this the way I do.
> This is not a transaction issue anymore. It started there,
> but now it's a
> simple problem: how to convey errors among results?
> The server sends a TDS7_RESULT packet followed by an ERROR
> packet. AIUI,
> the ODBC code makes the results available, stuffs the error
> into the hstmt (or something), but then frees the resource before the
> application has a chance to read the error. SQLExecDirect() returns
> SUCCESS instead of FAIL (or SUCCESS_WITH_INFO?).
> > It seems that calling _SQLFreeStmt(DROP) should
> > send cancel however SQLEndTran should just discard results.
> The easy fix
> > is to discard results (just calling tds_process_simple_query
> > perhaps...).
> The other client libraries don't discard or cancel results
> just because
> they see an error packet from the server. There's no need.
> It's enough
> just to pass along the message to the client and let him deal
> with it.
> The difficult change, it seems to me, is making
> SQLExecDirect()'s return
> code reflect the whole series of packets, not just the status
> of the last
> one. If it processes:
> it can't return SUCCESS just because that last DONEPROC was
> OK. It has to
> notify the client there was an intervening ERROR.
SQLExecDirect stop at first DONE, so it do not see the ERROR token and returns SQL_SUCCESS.
Assuming procedure contains just "SELECT @value / ( @value - @value )" procedure returns
DONEINPROC (with error)
In this case SQLExecDirect should return error (detected with DONEINPROC with error set, not with ERROR token)
More information about the FreeTDS