https://issues.apache.org/ooo/show_bug.cgi?id=125949

          Issue ID: 125949
        Issue Type: DEFECT
           Summary: Connecting to an existing dBase database defines
                    incorrect field widths
           Product: Base
           Version: 4.1.1
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: code
          Assignee: [email protected]
          Reporter: [email protected]

Created attachment 84301
  --> https://issues.apache.org/ooo/attachment.cgi?id=84301&action=edit
Example DBF and Screen Shots

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

-- 
You are receiving this mail because:
You are the assignee for the issue.
You are watching all issue changes.

Reply via email to