Saturday, October 17, 2009

Number precision and scale bug

Milos showed me this bug the other day and I could not believe it.

Number precision and scale does not work correctly in default ADF input field.

I searched metalink, I could not find something relevant

I reproduced it in a simple test case with Employees view object.

Employees Table has Salary field which is NUMBER(8,2) and CommissionPct NUMBER(2,2)
I also added a field on Employees table TO_PAY which is NUMBER(20,5)
I created a default input form.

When I try to enter value 123456.78 to salary which is a valid value I could not enter 8 digit
When I try to enter value 0.12 to CommissionPct I could not enter either 1 or 2 digit
When I try to enter value -123456789012345.12345 to ToPay field I could not enter the last 2 fields.

This issue is because when you drag and drop items on page it set precision the precision of the number ignoring fragment separator, sign symbol or 0 before fragment separator.

This is defined in input field property: maximumLength="#{bindings.Salary.hints.precision}"

You can eather remove maximumLength or set it to "#{bindings.Salary.hints.precision+1}" for Salary or +2 for percentages or even +3 for cases that you have only fragment digits like CommissionPct but you could also put negative number.
Take also into account that in some locale the negative number may have (###) format, meaning that you need +4 on maximumLength.

Also the number converter does not work correctly for numbers with more than 3 digits.
I tried to put 12345.12345 in ToPay field but when I submit I get back 12345.123 loosing the last 2 digits.

I try to fix this by setting ToPay converter min and maxFractionDigits
af:convertNumber groupingUsed="false"
minFractionDigits="5" maxFractionDigits="5"

then I could enter, see and submit all 5 fraction digits.

But when I try on an empty field to put number 123456789012345.12345 it is automatically converted to 123456789012345.12000 when I press tub. When I change it again it works ok.

Are these bugs?

Test case:


  1. This is probably bug 6944342 - the workaround is to set the "columns" on the JSF item to accomodate the extra space

  2. Thanks Grant
    I searched for that bug but it says:
    BUG cannot be displayed. Possible reasons are:
    The bug is not classified as publicly accessible ("non-public").

    What about the rounding of fraction digits?

  3. what a strange bug that you find in this program, I have the same in my knee anatomy myths project in 1998.

  4. This issue is because when you drag and drop items on page it set precision the precision of the number ignoring fragment separator