Another option is to save the Excel file as tab separated values. Using tabs as delimiters avoids some of the comma issues. Jim On Jul 30, 2015 6:07 PM, "R.Smith" <rsmith at rsweb.co.za> wrote:
> > > On 2015-07-30 11:12 PM, Sylvain Pointeau wrote: > >> Le jeudi 30 juillet 2015, Simon Slavin <slavins at bigfraud.org> a ?crit : >> >> Yes, as I wrote, this bad behaviour (which you could reasonably call a >>> bug) is documented. That's how Microsoft wrote Excel and that's the way >>> they want it to work, and that's how it will continue to work. >>> >>> Simon. >>> >>> There is a workaround for the leading 0, but you cannot have multi-line >> when doing this. It is one or the other, too bad! I though generating xml >> for excel instead of csv, but I didn't have time to try yet. >> > > Something I like to point out to clients everywhere: > > Excel is intended (much like Calc etc.) to be a financial spreadsheet > system, NOT a data-manipulation tool. Its Row/Column/Cell backbone simply > lends well to the latter and so people press it into service - but that > wasn't the design goal. > > On that note, if you output things to Excel in CSV (or TSV formats) and > you have columns suffering leading zero text, you can simply Prepend an > Equals sign. > > i.e. if this is your CSV: > > ID, Name, Age > "00017", John, 14 > "10044", Joan, 17 > "00038", James, 16 > > Which will import wrong losing leading zeroes, then change it to this: > > ID, Name, Age > ="00017", John, 14 > ="10044", Joan, 17 > ="00038", James, 16 > > and Excel will behave perfectly well without any added weird characters or > the like. > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
