On Wed, Sep 9, 2009 at 10:33 AM, Jim Showalter <j...@jimandlisa.com> wrote: > Microsoft also supports an XML standard for import/export. Whenever > possible, it should be used instead of CSV. It's not the > line-terminators that are the problem--the problem is CSV itself. > That's why Microsoft upgraded to supporting XML. They only support CSV > for backward-compatibility reasons.
with reference to our problem here, how does exporting data to XML help if one wants to then import it into sqlite3? As far as I can tell, sqlite3 doesn't support importing XML, or does it? > > ----- Original Message ----- > From: "Jean-Denis Muys" <jdm...@kleegroup.com> > To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> > Sent: Wednesday, September 09, 2009 6:09 AM > Subject: Re: [sqlite] Importing data into SQLite - text files are not > really portable > > >> >> On 9/8/09 22:24 , various people wrote: >> >>> Unfortunately, the 3 main families of small computer operating >>> systems >>> have 3 different definitions of what a text file is... >>> >>> DOS/Windows (PC): lines are terminated with CR+LF >>> Unix: lines are terminated with LF >>> Macintosh: lines are terminated with CR >> [...] >>> FYI: Mac excel does not separate rows with \r, but inserts a ^M >>> instead. >> [...] >>> From: "Kavita Raghunathan" <kavita.raghunat...@skyfiber.com> >>> >>> Yes, this works. Must have been my original csv file. >>> I was using mac based excel and I'll now try using the windows >>> based >>> excel. >> >> For the record, the Mac has not been using CR line terminations for >> many >> years now (2001). >> >> Microsoft, in its not very high wisdom, proposes in the latest Mac >> version >> of Excel, 4 export formats that might correspond, with useless >> names: >> >> 1- the main format at the top of the menu is named "Comma Separated >> Values >> (.csv)" >> It's a comma -separated, CR-terminated format, with characters >> encoded in >> MacRoman ( http://en.wikipedia.org/wiki/Mac_OS_Roman). >> As both line-termination and character-encoding conventions have >> stopped >> being used for many years, it's despicable from Micros__t to >> continue to >> name it as they do, and to propose it as the main choice. >> >> 2- secondary format named "Tab delimited text (.txt)" >> Same as 1-, except the separator is now a tab character. >> Totally useless format >> >> 3- secondary format named "Windows Comma-separated (.csv)" >> Line terminations: CR-LF (Windows convention) >> Character encoding: CP1502 (Windows extension to ISO-8859-1) >> This is the most useful format, as it's likely to work for >> interoperability >> with the Windows world. >> >> 4- secondary format named "MS-Dos Comma-separated (.csv)" >> Line terminations: CR >> Character encoding: CP850 ( http://en.wikipedia.org/wiki/CP850) >> A totally obsolete variant. >> >> Notably missing would be for example the *current* version: line >> terminated >> with LF and UTF8 encoding. >> >> I will stop there. Ranting on MS is bad for my nerves. >> >> Jean-Denis >> >> >> >> >> _______________________________________________ >> 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 > -- Puneet Kishor _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
