FreeTDS Development Group

["Thompson, Bill D (London)" <bill_d_thompson AT ml.com>]

James,

dblib/unittests/bcp.c works fine to both Sybase 11.9.2 and SQL server 2K,
after removing SYBCHAR from the is_nullable_type macro.

...The snapshot I'm working with is from february however...

Bill

> -----Original Message-----
> From: Thompson, Bill D (London) 
> Sent: 26 April 2004 16:46
> To:   'FreeTDS Development Group'
> Subject:      RE: [freetds] bcp broken on TDS 5.0
> 
> James,
> 
> > 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.  
> 
> Yes, I was tempted that way too... I think its a good idea, but it might
> have a significant impact on the code. I'll take a look and report back.
> 
> > 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've removed it, and the bug I was experiencing with ct-blk disappeared.
> let
> me check out the dblib unittest and report back.
> 
> > I'm glad you're working on ct-blk.  How's it going?  
> 
> 95% there...now of course I've gotten the benfit of hindsight, my new code
> is so much cleaner than the dblib version.
> I guess I *should* try and backport said improvements into dblibrary, but
> I
> am short of time...
> 
> 
> Bill
> 
> 
> 
> > -----Original Message-----
> > From:       Lowden, James K [SMTP:LowdenJK AT bernstein.com]
> > Sent:       26 April 2004 15:49
> > To: FreeTDS Development Group
> > Subject:    RE: [freetds] bcp broken on TDS 5.0
> > 
> > > 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.
> > 
> > 
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> ==========================================================================
> ====
> 
> If you are not an intended recipient of this e-mail, please notify
> the sender, delete it and do not read, act upon, print, disclose,
> copy, retain or redistribute it.
> 
> Click here for important additional terms relating to this e-mail.
>      <http://www.ml.com/email_terms/>
> 
> ==========================================================================
> ====
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

==============================================================================

If you are not an intended recipient of this e-mail, please notify
the sender, delete it and do not read, act upon, print, disclose,
copy, retain or redistribute it.

Click here for important additional terms relating to this e-mail.
     <http://www.ml.com/email_terms/>

==============================================================================