Skip to Content.
Sympa Menu

freetds - RE: [freetds] bcp broken on TDS 5.0

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] bcp broken on TDS 5.0
  • Date: Mon, 26 Apr 2004 10:48:56 -0400

> From: Thompson, Bill D (London) [mailto:bill_d_thompson AT ml.com]
> Sent: April 26, 2004 7:00 AM
>
> I don't know why SYBCHAR was added to the is_nullable_type()
> macro, but I
> assume there was good reason.
> It may be that we need to make a similar, but not identical,
> distinction for
> other functionality in our code.
>
> Can you shed any light on this ?

Hi Bill,

Some light, perhaps. It was me, as you know, who changed the macro, and I'm
sure it was because I discovered much NULL mishandling in bcp data. It was
right around then that I wrote the bcp unit test, to keep things from
breaking again.

I am tempted to invent a SYBCHARN datatype for the purposes of making this
evaluation more consistent. Whenever we're handed a SYBCHAR type from the
server, we inspect its nullability and change its type as need be. On the
way out, the reverse. The FreeTDS code would see SYBCHAR/SYBCHARN, but the
server would of course see only SYBCHAR.

I'm tempted because 1) it's what Sybase should have done in the first place,
and 2) it would mean that calls to macros like is_nullable_type() wouldn't
have to be followed a by special-case SYBCHAR test everywhere. What do you
and Frediano think?

I'd also be willing to bet that if you remove SYBCHAR from the
is_nullable_type() macro, you'd break src/dblib/unittests/bcp.c in a pretty
obvious way that a guy like you could rectify in short order. I wouldn't
stake a lot on that proposition, but it might be worth a try.

I'm glad you're working on ct-blk. How's it going?

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 we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to
inform and update our clients, prospects and consultants of developments
relating to our services and products, would not like to receive further
e-mail correspondence from the sender, please "reply" to the sender
indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New York,
NY 10105.






Archive powered by MHonArc 2.6.24.

Top of Page