FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

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