#171 Dbf data cannot be parsed correctly

[Anonymous]

For big "Numeric" data, for example, created by java.lang.Long, it cannot parse it correctly.
The easy repeat step is, create an attribute "big_id", assign value "1111111111111".
Then, use open shape file menu to open it. It will display '0" for "big_id".
Other dbf viewer can display the data correctly.

[Anonymous]

I checked the source codes DbfFile.java.
It can be fixed by add Long type if the width of the number is bigger than the range of Integer.

if (isInteger) { //its an int
301
302 try {
303 return new Integer(numb);
304 } catch (java.lang.NumberFormatException e) {
305 return new Integer(0);
306 }

[michael michaud]

Unfortunetely, adding a datatype to OpenJUMP is much more work than just changing how dbf is parsed.
Currently, OpenJUMP authorized data types are Geometry, Integer, Double, String, Date and Object.
Adding a Long data type (or Boolean or BigDecimal...) would require an important code refactoring.
The only solutions I can imagine between loosing the information and refactoring the whole code are :
- use the Double data type for a dbf field of type 'N' and length > 10 (you still can loose some information as the max length for a 'N' field is 18, which cannot be represented exactly with a double)
- use the String data type for a dbf field of type 'N' and length > 10 (drawback is that you loose the numeric type if the field is declared with a width > 10 even if the table contains only small ints. You loose the capability of sorting the field numerically and doing maths with it...)
- testing the whole dbf file to check if the column effectively contains big integers before deciding to cast it to a String or a Double

IMHO, changing OpenJUMP Integer type to Long would be a little less work than adding a new Long type but it also needs to review a lot of code.

[Jukka Rahkonen]

I made some tests with OJ r.4071.

• Input of value "1111111111111" into integer field is not accepted
• Updating field to "1111111111111" with Auto assign attribute does not accept the value. Instead it updates fields to "null" without telling user anything about it. It would be better to through an exception but that is worth another bug report.
• Updating field to "1111111111111" with Replace attribute value throws an error
  java.lang.NumberFormatException: For input string: "1111111111111"

Because it does not seem to be possible to create a faulty dbf file with the standard OpenJUMP tools I consider that this issue can be closed. I do not think it is a bug if OpenJUMP cannot show value "1111111111111" in integer field if some software has managed to save such because it means that the dbf file is invalid.