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: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: Changing return codes from tds_convert()
  • Date: Tue, 24 Sep 2002 17:23:49 -0400


> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: September 24, 2002 5:02 PM

> > I 'm actually becoming increasingly convinced that the TDS
> > layer should
> > never call the client message callback/client error handler. Errors
> > should
> > be returned to the calling layer, which will generate a client
> > callback/error handler invocation if needed.
>
> With you 100% on this one too. basically tds_convert only
> invokes the error
> handler right at the end, so it might as well be left to the
> calling API
> (which would be musch easier). I discussed this on the phone
> with JKL a couple weeks back.

For every complex problem, there is a solution that is simple, neat, and
wrong.
-- H. L. Mencken

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