https://issues.apache.org/ooo/show_bug.cgi?id=125949
--- Comment #1 from rosspjohnson <[email protected]> --- Re why the value ANT_GAIN=12.2 did not cause a failure. The non-failure suggests that the field length value of 3 is being interpreted as what is called the maximum "precision" of the field, i.e. the maximum number of digits that the field will allow rather than the field length. The DBF field definition is N,5,1 indicating a numeric field with length 5 and 1 decimal place. Experimenting further I tried copying the exmaple table within the same Base database as the source table and this did not fail. I tried modifying values in the table with the following results: 1) change the value ANT_GAIN=12.2 to -12.2. Result: accepted (does not exceed 5 characters total, does not exceed 3 digits total). 2) change the value ANT_BW=136.0 to -136.0. Result: error updating (exceeds the field length and 5 characters total). I'm guessing that the field length values seen in the Base table edit screens are the result of deducting the sign and decimal point characters from the total. That would explain why: N,8,0 (DBF) becomes Decimal 7,0 (Base), i.e. an integer with a sign character deducted. N,5,1 (DBF) becomes Decimal 3,1 (Base), i.e. a float with sign and point characters deducted. But I can't see why this would be done as both the DBF format and Base define these attributes as total field length and decimals, not precision and scale. -- You are receiving this mail because: You are the assignee for the issue. You are watching all issue changes.
