Skip to Content.
Sympa Menu

freetds - Re: [freetds] better errors

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] better errors
  • Date: Thu, 30 Jun 2005 09:49:33 +0200


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




Archive powered by MHonArc 2.6.24.

Top of Page