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: "Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>
  • To: "'TDS Development Group'" <freetds AT franklin.oit.unc.edu>
  • Subject: RE: Changing return codes from tds_convert()
  • Date: Tue, 24 Sep 2002 22:01:53 +0100


yay!

We discussed the "valid zero length" vs. TDS_FAIL issue a while back, and I
suggested then that we implement a TDS_CONVERT_FAIL return code instead. So
I'm with you on this one.

> 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.

<whisper> by the way Nick, how much did we agree on ? </whisper>

Bill


> -----Original Message-----
> From: Castellano, Nicholas [SMTP:Nicholas_Castellano AT acml.com]
> Sent: Tuesday, September 24, 2002 9:29 PM
> To: TDS Development Group
> Subject: [freetds] Changing return codes from tds_convert()
>
> I would like to change the return status codes from tds_convert().
>
> Currently, tds_conver() returns either a positive length from the
> successful
> conversion, or TDS_FAIL to indicate that something went wrong.
>
> This causes two problems:
>
> - A valid conversion of zero-length data will cause 0 to be returned,
> which
> is indistinguishable from a TDS_FAIL (== 0) return.
> char *src = "";
> CONV_RESULT cr;
> if (tds_convert(ctx, SYBCHAR, src, 0, SYBCHAR, 0, &cr) == TDS_FAIL)
> {
> /* Oops, was that really TDS_FAIL, or just a 0 length? */
> }
>
> - Currently, tds_convert() will call tds_client_msg() to invoke the client
> error handler. However, my experimentation with cs_convert() in Sybase's
> CT-Lib shows that the client message callback is never invoked*. So we
> should really pass back a return status to the caller and let it decide
> what
> to do in case of failure.
>
> Basically, I'm proposing to add a few extra negative return codes to
> tds_convert_noerror() in addition to TDS_CONVERT_NOAVAIL. Something like
> this:
>
> #define TDS_CONVERT_FAIL -1 /* Unspecified failure
> *./
> #define TDS_CONVERT_NOAVAIL -2 /* Requested conversion does not
> exist */
> #define TDS_CONVERT_SYNTAX -3 /* Syntax error in source field
> */
>
> The current tds_convert() would then be thrown away.
> tds_convert_noavail()
> would be renamed to tds_convert(), and become the exposed API. Callers
> could either check for specific return codes, or just check if it's less
> than 0 if uninterested in the reason for failure.
>
> Let me know if there are any objections to this plan.
>
> Cheers,
> --nick
>
> * 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.
>
>
> 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.
>
>
>
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')





Archive powered by MHonArc 2.6.24.

Top of Page