FreeTDS Development Group

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

> > 
> > > Inbound, the error numbers that libtds emits are db-lib 
> based, and the
> > > parameters include some ct-lib (I think) state.  ct-lib's 
> > > error numbering
> > > scheme is much saner and thus inconsistent with db-lib.  My 
> > > guess is ODBC
> > > uses another set altogether.  My idea is to have libtds 
> > > standardize on the
> > > ct-lib numbers, and let the others map to that.  
> > > 
> > 
> > ODBC support both native errors and "sql" errors. Native errors are
> > errors specific to database (MySql, SQL Server or whatever) 
> so it use
> > error code provided by tds_client_msg. sql errors (also called sql
> > state) are an iso standard used by ODBC itself and also 
> ctlib. I don't
> > know if ctlib use same errors used by dblib and ODBC but I 
> think so...
> 
> http://sybooks.sybase.com/onlinebooks/group-sd/sdg1251e/ctref/
> @Generic__BookTextView/6654;pt=6654;uf=0#X
> 
> (http://tinyurl.com/dasxy)
> 
> The macros for parsing a ct-lib message are CS_LAYER(), CS_ORIGIN(),
> CS_SEVERITY(), and CS_NUMBER(), found in cspublic.h.  To get this:
> 
> Severity:     CS_SV_COMM_FAIL (2)
> Number:               4
> Origin:               3
> Layer:                4
> 
> That's: 0x04030204 = 4,030,204.  SYBECONN is 20009.  
> 
> I'm glad to hear ODBC uses db-lib numbers, though.  Funny, that.  
> 

In ODBC are called native errors. It does not mean that using MySQL you
use dblib errors. The primary source for error in ODBC is SQL state, not
numeric error (that is, as said, driver dependent).

> > > If we're ever going to get timeouts to work according to 
> > > spec, we're going
> > > to have to let the handler have its say.  We need to 
> synthesize the
> > > meanings of all the handler conventions to convey clear 
> > > information back to libtds.  
> > 
> > Mmmm... perhaps we should call tds_cancel/exit inside error 
> handler...
> > only dblib require INT_CANCEL/INT_EXIT.
> 
> Maybe.  I think it would be easier to understand if db-lib 
> conveyed the
> user's intent via the return code.  
> 
> ct-lib:
> "CS_FAIL instructs Client-Library to terminate any processing that is
> currently occurring on this connection. A return of CS_FAIL 
> results in the
> connection being marked as "dead", or unusable."
> 
> db-lib:
> "Returning INT_CANCEL on timeout errors will kill the dbproc."
> 
> Looks the same to me.  :-)
> 
> Here's a little table:
> 
> Effect                                db-lib          ct-lib
> ------------------------------        --------------  ------------
> OK, no error                  n/a             CS_SUCCEED
> FAIL, conn OK !SYBETIME               INT_CANCEL      n/a
> FAIL, conn dead       !SYBETIME       n/a             CS_FAIL 
> SYBETIME retry                        INT_CONTINUE    CS_SUCCEED 
> SYBETIME FAIL, conn dead      INT_CANCEL      CS_FAIL 
> SYBETIME cancel, conn OK      INT_TIMEOUT     n/a
> abort program                 INT_EXIT        n/a
> 
> Reading Microsoft's dberrhandle() reference yet again, I see 
> that Sybase
> and Microsoft agree on the meaning of the return codes in 
> db-lib, except
> for one thing.  Elsewhere, out-of-range return codes are treated as
> INT_EXIT, and INT_EXIT aborts the program.  In Windows, 
> Microsoft treats
> out-of-range codes as INT_EXIT, and treats INT_EXIT as INT_CANCEL (not
> aborting).  
> 

Quite strange.

> Can you add a column to my table for ODBC?  
> 

ODBC works in a different way, it just store error in current
HDBC/HSTMT/HENV (connection/statement/environment respectively) and say
"go on". It's up to application (after function return) to decide if
issue a cancel (calling SQLCancel) or disconnect (SQLDisconnect) or
whatever (exit, SQLFreeHandle...)

...

bye
  freddy77