Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#171 Dbf data cannot be parsed correctly


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
    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
    302 try {
    303 return new Integer(numb);
    304 } catch (java.lang.NumberFormatException e) {
    305 return new Integer(0);
    306 }

  • 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.