Unfortunately, we already tried this, sed, and writing our own translation program in C.
In the best case it doubled (!) the CPU-time usage and ate more than one core at a time, which isn't acceptable in our environment. Making the change in place in the sqlite source has no observable impact. Most other programs and APIs which generate or read CSVs that we have seen treat them correctly according to the standard, regardless of platform. I too am sad that CRLF is mandated in the specification and still in wide use because of Windows. But the fact is that there are database import programs which can't deal with plain LF input. Which is insane, but there are large datasets being repeatedly imported into those programs. Please could you reconsider, or in the worst case could we consider a way to make it optionally output specification-complaint output? Thanks, - Peter On 24 July 2014 11:02, Richard Hipp <d...@sqlite.org> wrote: > On Thu, Jul 24, 2014 at 5:46 AM, Hick Gunter <h...@scigames.at> wrote: > > > How about piping your csv file through unix2dos? > > > > Yeah. Having a unix program generate \r\n line endings just seems wrong. > Standard or no standard. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
