FreeTDS Development Group

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

ZIGLIO, Frediano, VF-IT wrote:
> 
> > 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.  

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

Can you add a column to my table for ODBC?  

> >     tds_client_msg(tds, routine & layer & origin);
> > 
> > And make sure _dblib_handle_err_message() can deal.  
> > Fortunately, 15 isn't that many to do.  
...
> So it's wrong to remove TDSCONTEXT* parameter, used for error without a
> connection.

Thank you.  My mistake.  

> > Lastly, I have a question about TDSMESSAGE::priv_msg_type.  
> > It's written
> > to 5 times (once in mem.c, 4 in token.c).  It's never read.  
> > Anyone have
> > any idea what it's meant to do?  Also, I'd like to 
> 
> It useful to distingue from information to error but it's not used
> (level is used instead)

OK, then we don't need it.  

> > s/msg_level/severity/
> > and s/msg_number/msgno/ and s/msg_state/state/ if there are 
> > no objections.
> 
> I agree

Thanks.  

Regards, 

--jkl