Skip to Content.
Sympa Menu

freetds - Re: [freetds] dblib bcp, t0017 broken

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] dblib bcp, t0017 broken
  • Date: Fri, 27 Jan 2006 11:03:43 -0500

> From: ZIGLIO, Frediano, VF-IT
> Sent: Friday, January 27, 2006 9:26 AM
>
> > I don't understand code in bcp.c lines 1240 onwards. This is
> > yours and james' code...
> >
> > what is this byte its reading ? I don't understand what the
> > program is expecting to find here...
>
> Yes, you are right, I think patch came from Christos
>
> https://lists.ibiblio.org/sympa/arc/freetds/2004q1/thread.html
> https://lists.ibiblio.org/sympa/arc/freetds/2004q1/015049.html
> https://lists.ibiblio.org/sympa/arc/freetds/2004q1/015068.html
> https://lists.ibiblio.org/sympa/arc/freetds/2004q1/015077.html
> https://lists.ibiblio.org/sympa/arc/freetds/2004q1/015569.html
>
> Now... what this patch should fix? I'm trying to get a reply from
> https://lists.ibiblio.org/sympa/arc/freetds/2003q4/thread.html (Cf.
> "bcp is really busted" thread).

Cf. https://lists.ibiblio.org/sympa/arc/freetds/2004q1/015569.html

The patch was applied Fri Mar 12 04:04:30 2004 UTC, creating revision
1.91. I'm sorry, somehow I seem not to have made a ChangeLog entry.

Bill, as far as I'm concerned, hack away. I use bcp quite a lot, but
hardly ever in native mode. You may find the attached patch helpful; it
makes the errors clearer in the unit test.

I see several problems.

1. Native bcp is broken again. You and Freddy are looking at that.

2. dblib error processing is broken. The common.c error handler
returns INT_CANCEL, but t0017 doesn't receive an error. This is a
longstanding problem, but it's infected our unit tests. Other unit
tests also return errors, but I don't know yet which ones are expected
and which are broken.

3. (small problem) the common.c error handler writes to stderr, making
it unclear amidst stdout where precisely the message occured. For that
reason, I modified t0017 to write some of its feedback to stderr. Do
you think the handler should use stdout instead?

I don't know how much of this affects 0.64.

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential 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.

Attachment: t0017.diff
Description: t0017.diff




Archive powered by MHonArc 2.6.24.

Top of Page