FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Konrad J Hambrick wrote:
> 
> We are using either freebcp or MS BCP.EXE to automatically
> upload tens-of-GB of data every night on each of 20+ systems
> and my vote is for freebcp to work EXACTLY like MS BCP.EXE.

How do you handle errors?  Do you scan the error files?  Because bcp.exe
does not reliably return an error when there's a problem.  

FreeTDS is first and foremost an API library, and fidelity to those
specifications (and observed behavior) is the stated objective of the
project.  Your humble maintainer does not consider perfect compatibility
of the utility applications, on the other hand, to be very important. 
That said, if others do think it important and want to contribute toward
that end, my role is to facilitate and incorporate such contributions.  

In the instant case, we're discussing a very fine point: how should the
bcp utility respond to a line in a file with a field too wide for its
column?  We're already in the error domain.  It's the kind of thing the
vendor might change between versions.  In fact, *did* change when ANSI
compatibility was introduced.  Not only that: it's very fragile, because
the batch system (bcp) depends on a potentially changing server-side
environment it can't easily interrogate.  

Cedric ROUVRAIS wrote:
> FreeTDS should offer  an
> alternative binary rather than changing back and forth the binary based
> on who speaks louder. 

This strikes me as one of those things best solved with 

        #if ! MSDBLIB

No one wants both behaviors.  In fact, only a tiny number of people care
at all.  To me it makes sense to follow the --enable-msdblib configure
option.  

But: how do you intend to discover the value of ANSI_WARNING?  

> set ANSI_WARNING needs to be set at the server level. You can't
> change it that easily.

I changed it at the database level with sp_dboption.  I tested with a
non-nullable CHAR column.  

--jkl