To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=115420
                 Issue #|115420
                 Summary|Base: NULL date import breaks type recognition & may c
                        |rash OOo 3.3.0 RC3
               Component|Database access
                 Version|OOO330m13
                Platform|PC
                     URL|
              OS/Version|All
                  Status|UNCONFIRMED
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P2
            Subcomponent|none
             Assigned to|dbaneedsconfirm
             Reported by|yutgor





------- Additional comments from yut...@openoffice.org Fri Nov  5 03:56:47 
+0000 2010 -------
When importing into Base any Calc spreadsheet with /y/ data rows and a column of
formatted dates, if the max lines for auto-type recognition is /x/ and the cell
on data row /x/+1 or /y/, whichever is smaller, in the date column is empty, OOo
incorrectly auto-recognises the next column to have a DATE type if it's
non-numeric (e.g., text).  Manually changing it to a Text type shows correct
data but the format example incorrectly shows a date string.  Changing it to
Memo type will result in *corrupt* data or, if any data contain the string
'ORA-20001' and the OS is Windows, even a *crash* on opening the imported table.

[NB: The reason why this fails on data row /x/+1 vs. /x/ is because of another
bug.  See Issue #115308.  If Issue #115308 is fixed, then the current bug will
occur on data row /x/.]

This problem is attested in the following builds and OS:
- OOO320m12 on Ubuntu 10.04 in Oracle VM VirtualBox 3.2.10 r66523 on 64-bit
English Windows Vista Business SP2
- OOO320m18 on 64-bit English Windows 7 Ultimate
- OOO320m19 on Ubuntu 10.10 in Oracle VM VirtualBox 3.2.10 r66523 on 32-bit
English Windows XP Professional SP3
- OOO330m12 on 32-bit English Windows XP Professional SP3
- OOO330m13 on 32-bit English Windows XP Professional SP3

Test case:
I. Create new database:
        A. Launch Base.
        B. Select 'Create a new database'.
        C. Click 'Next'.
        D. Select 'Yes, register...'.
        E. Check 'Open the database for editing'.
        F. Uncheck 'Create tables...'.
        G. Click 'Finish'.
        H. Type an arbitrary file name.
        I. Click 'Save'.
II. Open the attached "b-crash-import-null_date.ods" file.  Note the following:
        A. It contains 2 sheets each having 10 data rows & a column of dates 
with data
cells 5 and 10 being empty.
        B. The 'Date' column, excluding the header but including the empty 
cells, has a
date format of YYYY-MM-DD set via <ctrl-1>|Numbers|Date.
        C. Data row 8 in sheet 'Wrong Type and Crash' contains the string 
'ORA-20001',
which is its only difference in content from sheet 'Wrong Type No Crash'.
III. Test no crash scenarios:
        A. Select sheet 'Wrong Type No Crash'.
        B. Copy data:
                1. Press <ctrl-home>.
                2. Press <ctrl-shift-end>.
                3. Press <ctrl-c>.
        C. Switch to Base.
        D. Test scenario 1:  wrong format example
                1. Create table:
                        a. Select 'Tables' in the Database panel.
                        b. Right-click in the 'Tables' pane.
                        c. Select 'Paste'.
                        d. Give the table an arbitrary name (or use default).
                        e. Select 'Definition and data'.
                        f. Check 'Use first line...'.
                        g. Check or uncheck 'Create primary key'. (Doesn't 
matter.)
                        h. Click 'Next'.
                        i. Click double right arrows.
                        j. Click 'Next'.
                        k. Set max lines for auto-type recognition to 4 or any 
value >= 9 (i.e.,
actually reading 5 or 10 lines).
                        l. Click 'Auto'.
                        m. Select the 'Desc' field.  Note the field type has 
been incorrectly
recognised as 'Date [ DATE ]'.
                        n. Change field type to a Text type.
                        o. Click 'Create'.
                        p. Depending on the setting in step g, a dialog box may 
pop up asking to
confirm primary key creation.  Click 'Yes' or 'No'.  (Doesn't matter.)
                2. Open table:
                        a. Double-click on the table created in step 1.  Note 
the 'Desc' column shows
correct data.   
                        b. Close table data view window.
                        c. Right-click on table.
                        d. Select 'Edit'.
                        e. Click on the 'Desc' field.  Note the 'Format 
example' field at the bottom
pane incorrectly shows a date string ('1900-01-01' on Win, '01/01/00' on Ubuntu,
or even some other value depending on the OS locale).
                        f. Close table design window.
        E. Test scenario 2:  corrupt data
                1. Repeat D.1.a-c.
                2. Give the table a different name.
                3. Repeat D.1.e-m.
                4. Change field type to Memo.
                5. Repeat D.1.o-p.
                6. Double-click on the table created in step 5.  Note the 
'Desc' column shows
*corrupt* data.
                7. Repeat D.2.b-f.
IV. Test crash scenario:
        A. Switch to Calc.
        B. Select sheet 'Wrong Type and Crash' in the .ods file.
        C. Repeat steps III.D.1.a-c.
        D. Give the table a name different from what has been created so far.
        E. Repeat steps III.D.e-j.
        F. Set max lines for auto-type recognition to any value >= 9.
        G. Repeat steps III.D.l-m.
        H. Repeat steps III.E.4-6.  Now OOo displays *corrupt* data in the 
'Desc'
column up to data row 7 (data row 8 contains the string 'ORA-20001') and then
*crashes* if the OS is Windows; if the OS is Ubuntu, *corrupt* data is shown w/o
crashing.

Control cases:
If any of the following conditions is fulfilled, then the problem won't occur:
1. Data cell /x/+1 or /y/, whichever is smaller, of the date column contains a
date (e.g., by setting max lines to other values in step III.D.1.k) even though
some other cells in the column may be empty.
2. The next column is formatted with the @ format code via
<ctrl-1>|Numbers|Text.  Note the default format is 'General'.
3. Fields are manually given their correct types w/o clicking 'Auto'.
4. Importing from Excel.  (Try repeating the above tests with the attached .xls
file.)
5. Importing from Calc in OOO300m9.

See attached test results across different builds and applications
("b-crash-import-null_date-results.ods").  They indicate a regression from a
previous build, as text recognition was correct, data was correct, and there was
no crash whereas starting at least from OOO320m12 text recogition may fail and
result in corrupt data or even a crash.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org
For additional commands, e-mail: issues-h...@dba.openoffice.org


---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org

Reply via email to