FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

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

Look at ChangeLog-2004.

> 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 agree more verbose is better. I noted that in dblib unittests there
are a lot of

        while (dbresults(dbproc) != NO_MORE_RESULTS) {
                /* nop */
        }

I don't like that rows that much. What happen if dbresults keep
returning ERROR?? Try to delete PWD file and execute t0011. After 20
minutes I realize that test was in an infinite loop (all make check with
valgrind take 20 minutes...)

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

I don't understand INT_CANCEL problem... which error is not reported? I
noted that t0017 just store error in ret variable... it should check it
too (and even rows_copied).
Yes, many unittests return errors in stderr but this is usually
expected.

> 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 think stderr is for error while stdout for normal output. Notes like
I'm doing this should go to stdout while errors from server to stderr.
The problem is expected errors (the question is: stdout or stderr?).
Personally I don't understand code like

  fprintf(stdout, "xxx\n");

instead of

  printf("xxx\n");

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

I think all :) I fixed only bcp problem with fseek (already backported).

freddy77