FreeTDS Development Group

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

On Fri, 30 Mar 2012 01:21:21 -0400
a g <mewalig AT gmail.com> wrote:

>  Instead, I get an error message saying that I attempted to copy an
> oversized row and the copy failed, but the copy actually will have
> inserted a row of jumbled data. 

You are undoubtedly not describing the file correctly to freebcp, or
the file does not match the table.  That message usually means freebcp
didn't recognize the EOL as a row terminator.  

> I compiled ... with both nmake and with mingw

Since you're running in Windows, you need to be sure 

1.  What the line ending is in the file, probably 0x0D0A
2.  That you express that correctly to freebcp

Logically, because cmd.exe doesn't recognize '\' as an escape
character, "freebcp .... -t \r\n" should work.  YYMV if you're using
another shell.  

For BCP the server requires the client to format the data, and to
format them correctly.  Sometimes if the client gets it "sort of
right" the server will place the data as received into the table.
>From the server's point of view, the data were correct insofar as they
didn't violate any of the rules of the table.  On retrieval the data
are "jumbled" because there were not placed according to expectation.  

Could freebcp do a better job of working this out, of making sure the
"line" read from the file corresponds to a row defined in the target
table?  Yes, probably.  Certainly it can count columns, and certainly
it's odd to find a file with "one giant line" because the line ending
was incorrectly specified.  I don't think inferring a line ending would
be so bad or so hard.  Just a SMP.  

HTH.  

--jkl