On 3/27/2014 7:25 PM, Morten Welinder wrote:
Unfortunately, I believe the configurable text importer also fails in the same way. With the attached .csv file I get identical results either by automatic importation or by using the configurable text importer (setting " as the text indicator).The text indicator has nothing to do with this. On the third page, select "Text" instead of "General".
Do you mean define column 1 as text? That only works if all the entries in column 1 are indeed intended as text. This is often not the case, particularly, for example, if you are trying to read a table that has numeric data with text column labels.
I think you are right about the .csv standard. What a mess.
I just discovered that the same problem occurs with other data
types. Inexplicably, "10.2.4, 4" is imported as type General and
treated as text, but "10.2.4" is usually (but not always!) converted to
a date, depending on locale. "$4" is converted to currency, but "$4+$6"
is type General and treated as text. "237" is converted to a number,
etc. So the syntax is not only irregular, but the results are
unpredictable. Why not just import all of these as text?
Take a look at the attached files test4.csv and test4.gnumeric, which give an example with actual and intended results. Other spreadsheets don't do much better than Gnumeric. Excel 2000 also misses three cells in test4, while LibreOffice makes a total mess of it. It would be so simple if enclosing data in quotes " " really meant that it would be imported as text. I can't think of any reason why non-text data should ever be enclosed in quotes.
Why shouldn't this just work? If I filed a bug report, do you think there is a chance that it would ever get fixed?
Attachment:
test4.gnumeric
Description: application/gnumeric
Attachment:
test4.csv
Description: Text document