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: "Pickett, David" <David.Pickett AT phlx.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] dblib bcp, t0017 broken
  • Date: Mon, 30 Jan 2006 09:45:07 -0500

Just from the distance, it sounds like the unit test found a valid weakness.
Maybe bcp should fflush() or fclose() buffered outputs at a transitional
point where the error checking is important, in the spirit of a commit, and
handle and meaningfully report any error there, including unexpected EOF?
Then, both unit tests and users get the benefit of timely error detection,
while running faster with outputs buffered.

Usually, stderr is usually unbuffered, presumably so you get some hint of
error location in your logs even if, for example, your app gets SEGV in the
middle of something like fprintf(stderr,"Invalid mysub() return: %s\n",
bad_pointer ).

Best regards,

David

-----Original Message-----
From: James K. Lowden [mailto:jklowden AT freetds.org]
Sent: Saturday, January 28, 2006 1:58 PM
To: FreeTDS Development Group
Subject: Re: [freetds] dblib bcp, t0017 broken


Frediano Ziglio wrote:
> Il giorno ven, 27/01/2006 alle 15.10 -0500, Lowden, James K ha scritto:
> >
> > Output:
> >
> > bcp_exec... DB-LIBRARY error (severity 3, dberr 20070, oserr 0,
> > dberrstr I/O error while reading bcp datafile, oserrstr Undefined
> > error: 0):
> > done
> >
>
> Mmm... here there should be no error, probably bcp.c detect eof like
> error.

There shouldn't be an error if the eof is normal -- when we're looking for
column 1 data. If we hit eof while reading data in the middle of a row,
it's an error. I haven't looked at t0017.in carefully, but if the file
doesn't match the table, it's quite common to hit eof unexpectedly (even
with the vendors' bcp).

> > Normally I agree. The problem is that unit test errors can be
> > confusing.
>
> This has to to with buffering using setbuf(stdout, NULL); setbuf(stderr,
> NULL) will fix this problem.

OK. I knew it was caused by buffering. We can set stdout to be
unbuffered in the unit tests. That way the errors will show up where they
belong.

> I think is better to release an RC1 with a known problem (native bcp).

Agreed.

Regards,

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page