Skip to Content.
Sympa Menu

freetds - RE: Changing return codes from tds_convert()

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Castellano, Nicholas" <Nicholas_Castellano AT acml.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: Changing return codes from tds_convert()
  • Date: Tue, 24 Sep 2002 18:15:14 -0400


ctlib does need fixing -- that's precisely what's at stake here.

The fact that the TDS layer is calling tds_client_msg() with lots of magic
numbers is a clue that something is wrong here.

The fact that these magic numbers appear only in <sybdb.h>, a header
specific to dblib, is another clue.

We could put a compatibility shim in ctlib to intercept and translate the
dblib error codes (and throw away ones that don't apply). To my mind, that
would be a kludge, not a fix.

The idea here is to provide a nice clean division of responsibility between
libtds and the user API's. libtds will provide return codes saying "Here is
what went wrong. Deal with it." The client API's will then do whatever is
appropriate for that API, including calling client message callbacks or
error handlers as appropriate.

As I continue with this effort, the interfaces between the two layers will
become cleaner, the ambiguities of meaning will be removed, the magic
numbers will go away, and both dblib and ctlib will behave closer to their
Sybase counterparts. I think these are all useful and worthwhile goals.

In the long run, we may still have to generate some client messages at the
TDS layer. I expect these will end up looking a lot more like ctlib client
messages than dblib error messages when all is said and done...

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu]
Sent: Tuesday, September 24, 2002 5:24 PM
To: TDS Development Group
Subject: [freetds] RE: Changing return codes from tds_convert()

[...]

ATM I'm not convinced ct-lib just doesn't need fixing, and error message
emission could stay in libtds. That would be, um, simple and neat.

However, you two smart guys are working way harder on this than I am and
know much better what you're doing. So I'm sure the reason to move error
messages out of libtds is clear to you. Best would be if you made it clear
to me too; that way Papa Brian can read your treatise and rest well
comfortable in the knowledge that his code is in good hands.

Regards,

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.






Archive powered by MHonArc 2.6.24.

Top of Page