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: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] bcp broken on TDS 5.0
  • Date: Mon, 26 Apr 2004 16:45:54 +0100

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

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





Archive powered by MHonArc 2.6.24.

Top of Page