FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il giorno mar, 06/12/2005 alle 15.07 -0500, Lowden, James K ha scritto:
> > From: Li, Maggie (IT)
> > Sent: Tuesday, December 06, 2005 1:49 PM
> > 
> > I believe I used the 0.63 this time:
> ...
> >   $Id: freebcp.c,v 1.34.2.1 2005/02/03 09:39:14 freddy77 Exp $ 
> 
> Yes, you do.  
> 
> > Out of 11 million something rows, freebcp finished with no
> segmentation
> > fault, but only close to 6 million rows copied.  Anyone can think
> > of any reason why?
> 
> Very peculiar.  I actually had that very same thing happen to me with
> Microsoft's library.  Turned out the target table had a computed column
> defined for it.  I don't know why, but the server accepted every other
> row.  
> 
> See if you can load 100 rows.  Check your DDL, and check your datafile
> with a hex editor to make sure it's delimited exactly as you want (not,
> say, with an extra CR before the linefeed).  There's no reason that 100
> rows should load successfully and 100 million rows not.  
> 
> If the first 100 rows work, try the last 100, and a middle chunk.  It's
> something in either the data or the server; it would be a miracle if
> FreeTDS could somehow succeed in skipping some rows.  It's hard enough
> to parse and load them, let alone dropping some bytes and not upsetting
> the protocol.  
> 
> If you can narrow down the problem and isolate it to freebcp, I'd be
> happy to look at it.  
> 
> HTH.
> 

Well... if we use ftell/fseek to handle large files any file larger than
2Gb can be a problem... we _did_ not support large file (ftello/fseeko).
Naturally I just committed a patch :-) It should be in tomorrow
snapshot. I don't think that windows platform have ftello/fseeko however
any new unix platform should do.

freddy77