FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

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