Skip to Content.
Sympa Menu

freetds - RE: [freetds] ODBC - binary, row count and compatibility

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] ODBC - binary, row count and compatibility
  • Date: Tue, 9 Mar 2004 15:57:21 +0100



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




Archive powered by MHonArc 2.6.24.

Top of Page