Skip to Content.
Sympa Menu

freetds - 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: "'freetds AT franklin.oit.unc.edu'" <freetds AT franklin.metalab.unc.edu>
  • Subject: Changing return codes from tds_convert()
  • Date: Tue, 24 Sep 2002 16:29:25 -0400


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.






Archive powered by MHonArc 2.6.24.

Top of Page