Apache OpenOffice (AOO) Bugzilla – Issue 70206
CSV imported fields not recognized as numbers
Last modified: 2016-04-03 17:00:47 UTC
When creating a database using an existing CSV file, Base does not recognizes some fields as being numbers. The fields not recognized are : - the negative values (ex : -63) - the numbers containing more than 3 digits (ex : 1234) Some explanations : It looks like Base uses the first line to determine if a column contains "text", "doubles", "dates"... If the number is not in the criteria (a number of less than 4 digits) it is set as text. This behavour is annoying because if we want to link that dataBase in Calc and do calculations on it, those fields recognised as text are not computed. To reproduce the issue : - Download the example file, - create a database (text file) - select the csv file - double click on the table corresponding to the CSV fil - right click to check the format of each column to check if it is text or number.
Created attachment 39638 [details] The CSV file showing the behaviour
clu -> pagalmes: as you have already written, in text databases, the first line after the headder is used to define the format (this is standard in text databases and a wanted behavior => no bug) - but i could imagine, that this rather old definition could be improved by anything like a format engine, that checks all values and after that define the format -> so i send this issue as a 'feature enhancement' to the requirement team
Any news?
I think this should be treated as a defect rather than a request for enhancement. Consider the following two csv files: File 1: "One";"Two";"Three" 1;2;3.00 4;5;6.78 9;8;7.65 File 2: "One";"Two";"Three" 1;-2;3.00 4;5;6.78 9;8;7.65 In file 1, column "Two" is imported as numbers, in file 2, the column "two" is imported as text. The only difference is that the second file contains a negative number in the first line, but it is still a number. This still happens in 3.0.1
All the examples given work in 4.2.0-dev and even 3.2.0: negative numbers and numbers with more than 3 digits are recognized as being numbers. The bug was probably fixed between the reported version (2.0.3) and 3.2.0, so resolving fixed.