FreeTDS Development Group

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

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