Skip to Content.
Sympa Menu

freetds - [freetds] mapping ct-lib errors

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: TDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] mapping ct-lib errors
  • Date: Mon, 18 Jul 2005 02:12:37 -0400

This weekend I converted db-lib to use a simpler error-message function
internally. When a db-lib function wants to call the application's error
handler, it calls dbperror(dbproc, msgno, errno). (If no OS error, zero
for errno.) This is really just a generalization of Bill's function in
bcp.c.

That cleans up db-lib quite a bit, because the error messages are
localized in one array, and dbperror() will call tds_dump() as
appropriate.

I did not address calls from libtds up to the db-lib error handler. Yet.
As you may recall, ct-lib and db-lib use very different error numbers and
message texts, with ct-lib's being much more detailed. At present, we
pass db-lib error numbers into ct-lib's error handling system, which worse
than just ugly: it's wrong. We need to have libtds emit error numbers
that each client library can interpret. At the very least, we need a way
to map between db-lib and ct-lib errors.

If you doubt me, look for error SYBECONN, 20009, "Unable to connect". I
think the right ct-lib error for that is 0x05030513 = -84083987 (the sign
is always flipped). You'll find 20009 appears in net.c and sybdb.h, but
not in ct-lib. AFAICT, ct-lib passes that error code through to the
application, and no correctly written ct-lib app will understand it.

The first step was to enumerate ct-lib error numbers, which is what the
attached file does.[1] Second is to map the few that libtds emits. Here
they are:

2400, 2401, 2402, 2403, 2404, 20004, 20006, 20006, 20009, 20014, 20019,
20020

I wanted to pass the ct-lib error to db-lib and ODBC, and have them map
back to the db-lib error number, but that's actually quite difficult, and
maybe more work than it's worth. Instead, if we could give libtds a way
to know which client library it's dealing with, it could do its own
mapping and pass each library its preferred error code. Or do we do that
already? I didn't find it.

It's still the client library's job to pass back a libtds return code, so
we can handle timeouts consistently. I haven't reduced the permutations
to a minimal set yet.

Once we fix the libtds <-> client-library interface, we'll be able to pass
retry/timeout codes from the client-installed error handler all the way
back to the network read/write functions.

--jkl

[1] Not committed yet; I'm not sure of the name or just where it will be
used.

Attachment: tds_library_errors.h
Description: Binary data



  • [freetds] mapping ct-lib errors, James K. Lowden, 07/18/2005

Archive powered by MHonArc 2.6.24.

Top of Page