[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
> information
> 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:
>
> 81(TDS7_RESULT)
> ff(DONEINPROC)
> 81(TDS7_RESULT)
> aa(ERROR)
> ff(DONEINPROC)
> 79(RETURNSTATUS)
> fe(DONEPROC)
>
> 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
TDS7_RESULTS
ERROR
DONEINPROC (with error)
DONEPROC
In this case SQLExecDirect should return error (detected with DONEINPROC with error set, not with ERROR token)
freddy77
More information about the FreeTDS
mailing list