Skip to Content.
Sympa Menu

freetds - Re: [freetds] better errors

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] better errors
  • Date: Wed, 29 Jun 2005 23:48:31 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page