FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

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