https://bz.apache.org/ooo/show_bug.cgi?id=127301
Issue ID: 127301
Issue Type: DEFECT
Summary: Connecting to an existing dBase database defines
incorrect field widths
Product: Base
Version: 4.1.3
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: Normal
Priority: P5 (lowest)
Component: code
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Issue ID 125949 is a duplicate of this issue. We are opening a new issue
because that issue ID is marked as CLOSED OBSOLETE but has not been resolved.
There is no change to the previous description, which was:
I have a set of DBF tables in a directory that I connect Base to as a new
database. I can view the data etc. in Base and it seems normal but if I copy a
table to, for example, another newly created Base HSQL database I get an error
"SQL STATUS: 22001 - Error code: -124" "Value too long in statement ..." (see
Base_DBF_Table_Copy.png inside the ZIP file attachment).
I checked the source table definition and found that the fields for all the
DECIMAL[NUMERIC] fields are shorter than defined in the DBF file.
I confirmed the DBF field widths by opening the DBF table in Calc (see
Calc_DBF_Field_Widths.png inside the ZIP file attachment).
In the example DBF table inside the attachment the fields with shortened field
lengths in Base are:
ANT_ID
Length 7
Decimals 0
ANT_GAIN
Length 3
Decimals 1
ANT_FB
Length 3
Decimals 1
ANT_BW
Length 3
Decimals 1
(see Base_DBF_ANT_ID_Field_Width.png and Base_DBF_ANT_BW_Field_width.png in the
ZIP file attachment)
In Calc the column headers display the correct definitions:
ANT_ID,N,8,0
ANT_GAIN,N,5,1
ANT_FB,N,5,1
ANT_BW,N,5,1
(see Calc_DBF_Field_Widths.png inside the ZIP file attachment).
In the example DBF table "antenna.dbf" the first value that I determined
produces the error on copy is in the row where ANT_ID = 46, in the column
"ANT_BW" with value "136".
This was identified by:
1) observing that the copy succeeds if only the ANT_BW column is omitted from
the copy,
2) including only the ANT_BW in the copy and stopping the copy at the error
then viewing the incomplete copy of the table in the destination Base database,
where the last row copied was the row immediately before this row.
However, this should not be the first point of failure for the copy, so there
appear to be other problems around enforcing field lengths. For example, why
doesn't the copy fail at the row where ANT_ID = 3 and the ANT_GAIN = 12.2? This
value exceeds the field length (3).
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.
Confirmed as still an issue in 4.1.3 using the same DBF file and process as
before. See the new ZIP attachment for updated screenshots.
--
You are receiving this mail because:
You are the assignee for the issue.
