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: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] ODBC - binary, row count and compatibility
  • Date: Tue, 9 Mar 2004 09:44:01 -0500

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.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page