[Libreoffice-bugs] [Bug 42747] New: EDITING VIEWING max/min values in "currency field" columns of table controls in db forms are wrongly interpretated

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Nov 9 17:40:16 CET 2011


https://bugs.freedesktop.org/show_bug.cgi?id=42747

             Bug #: 42747
           Summary: EDITING VIEWING max/min values in "currency field"
                    columns of table controls in db forms are wrongly
                    interpretated
    Classification: Unclassified
           Product: LibreOffice
           Version: LibO 3.4.4 release
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Database
        AssignedTo: libreoffice-bugs at lists.freedesktop.org
        ReportedBy: cluster15 at web.de


Created attachment 53333
  --> https://bugs.freedesktop.org/attachment.cgi?id=53333
test case database caontaining currecny field wrongly interpretated

When you create a database form, which contains a table control in which a
column is of type "currency field", the "value max." of the column is
effectively divided by 10^n where n is the number corresponding to its "decimal
accuracy" property.

As an example :  

"Value max."|"Decimal accuracy"|Actual max value|Expected max value  
1000000.00      2                  10000.00            10000000.00  
1000000.000     3                  1000.000            10000000.000  

The same happens to minimum values correspondingly. 

This does not happen to normal "numeric" fields inside the table control.  

This does not happen for "currency fields" outside of a table control.  

Tested under Linux/Mac OS 10.6 with postgresql as backend (via jdbc) and also
using the HSQL backend (see below for test database). OpenOffice suffers from
the same bug und the following additional OSs Windows XP/Vista (32bit) 

Attached is a test database containing one table and 3 forms (using the HSQL
backend): 

The database table contains 6 columns of type double. 

The forms:

Form "test_simple_fields":

contains "currency fields" for the corresponding db-table columns with the
following max./min values:

real1 : 1000000.00/-1000000.00
real2 : 12345,67/-12345,67
real3 : 1000000.00/-1000000.00
real4 : 12345,67/-12345,67
real5 : 1000000.000/-1000000.000
real6 : 1000000.000/-1000000.000

Form "test_table_control":
contains "currency fields" for the corresponding db-table columns with the
following max./min values:

real1 : 1000000.00/-1000000.00
real2 : 12345,67/-12345,67
real3 : 100000000.00/-100000000.00
real4 : 1234567,00/-1234567,00
real5 : 1000000.000/-1000000.000
real6 : 1000000000.000/-1000000000.000

Form "test_combined" 

contains both controls in one form.... 

In the table control multiplying the min/max values by 10^n (where n is the
number of its decimal accuracy property) provides the "correct" behaviour but
does _not_ constitute a valid workaround in my eyes. This was done in the
columns real3 real4 and real6 of the table controls in the test database to
check whether the decimal accuracy actually works (like for 12345.67 etc). 

Depending on via which control you use to change/enter the data the values in
the database table may or may not be correct. If the table control only
displays values exceeding its limits, the database entries are still correct,
but incorrectly displayed. Only after changing the values via the table control
the lower limits are enforced. 

Please play around with the forms and data. 

NOTE: Exceeding the max/min value leads to a rather silent change of the value
in the database entries (no warning no flashing, I admit the change is visible
in the control) I am not certain, that this is "wise"....

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Libreoffice-bugs mailing list