Bug 51605 - Field add corrupts table
Summary: Field add corrupts table
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Tables
  Show dependency treegraph
 
Reported: 2012-06-30 13:37 UTC by walkerkorea
Modified: 2023-04-05 15:09 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Database shows table before and after relocate columns by GUI (3.64 KB, application/vnd.sun.xml.base)
2013-01-22 19:34 UTC, Robert Großkopf
Details
Describes, how to reproduce the bug. (67.35 KB, application/vnd.oasis.opendocument.graphics)
2013-01-22 19:41 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description walkerkorea 2012-06-30 13:37:00 UTC
Version: LibreOffice Base 3.5.4.2
Build: 165a79a-7059095-e13bb37-fef39a4-9503d18
OS: Windows 7 Home Premium (32-bit).

Scenario:
Table X has 3 fields A, B, and D, with rows with data. You edit table X, and add field C. You cut field D, move to end, and paste after C.

Desired result:
Open Table X and it shows 4 fields A, B, C and D, in that order. Able to rename fields, and add new fields, and have them display when you open X. Copy table X to X2, and both field definitions and data are copied to X2.

Actual result:
Open Table X, and it shows 3 fields A, B, and C, but field C has data from old D. Edit Table X, and it shows 3 fields A, B, and D. Inconsistent results if you attempt to rename D (/C) field, or add new field with name C or D. However, even if you are able to rename D as D1 and back to D, and add new field C, the new field C will not appear when you open X, and field D will still be named C.

If you attempt to copy and special paste table X to X2, it fails to copy the data, but 3 fields are named A, B, and D.

Reproducible? Yes. Able to duplicate this error, with same results.
Comment 1 Robert Großkopf 2012-07-22 08:57:47 UTC
You can not sort the columns while editing the table in the GUI. If you will change a table and put C at the place you wish, this would only work with a SQL-command in the HSQLDB:
ALTER TABLE "X" ADD "C" VARCHAR(25) BEFORE "D";
The changes in the table were made, when you save the table. So when you cut "D" and put "C" at this position it is recognized as a renaming of the column.
In the HSQLDB there is no possibility to cut and paste a column.
Comment 2 Jochen 2012-08-28 18:38:04 UTC Comment hidden (no-value)
Comment 3 Robert Großkopf 2013-01-22 19:34:22 UTC
Created attachment 73473 [details]
Database shows table before and after relocate columns by GUI
Comment 4 Robert Großkopf 2013-01-22 19:41:34 UTC
Created attachment 73474 [details]
Describes, how to reproduce the bug.

There is a possibility to cut and paste fields in the table-editor of the Base-GUI. Users might think, that it would cut and paste the whole content of the field (the whole column). But this function cuts and pastes only the name and the type of the field. So the old contend appears at another position of the table. In the example-database a field of a birthday (DATE) is changed to a field of a street (VARCHAR) - the date of the birthday appears as varchar in the street-column.
Comment 5 Robert Großkopf 2013-01-22 19:43:35 UTC
The behavior is the same on Windows and other platforms.
This bug exists since the first version of LO.
Changed the bug to New.
Comment 6 Alex Thurgood 2015-01-03 17:38:28 UTC Comment hidden (no-value)
Comment 7 QA Administrators 2016-01-17 20:02:49 UTC Comment hidden (obsolete)
Comment 8 Robert Großkopf 2016-01-20 17:44:01 UTC
Bug still exists with LO 5.1.0.2, OpenSUSE 42.1 Leap, 64bit rpm Linux.
Comment 9 walkerkorea 2016-01-21 19:43:27 UTC
Tested LO 5.0.3.2, Windows 10.

My original post was muddled, I'm afraid, but a bug still exists in 5.0.3.2, and I can clarify as follows:

Scenario: "Attempt to insert a field, or reorder fields."
Create table Mailing with 3 fields: Last_Name, First_Name and City. Exit editing mode and open Mailing for data entry. Add 1+ records to Mailing with appropriate data for each field. Edit Mailing. Add field Address at the end. Cut field City, move to end, and paste after Address. Exit table editing mode. Immediately open table Mailing for data entry.

Desired result:
Mailing has 4 column headers, in this order: Last_Name, First_Name, Address, City. Fields Last_Name, First_Name and City have appropriate data, as before. New field Address is empty.

Actual result:
As desired, except that field City is empty, and new field Address has city data.

Why this is really a bug: Otherwise, how is a LO Base user supposed to re-order the columns, post facto?! Of course it's better to plan your table design, but sometimes new requirements come in, or you must tidy up someone else's poor design. Maintenance is easier when tables are orderly, and so is entering or editing data in table mode. It'd be nicer to be able to drag fields, in table edit mode, to re-order them.
Comment 10 QA Administrators 2017-03-06 13:58:46 UTC Comment hidden (obsolete)
Comment 11 Robert Großkopf 2017-03-06 16:01:43 UTC
Bug still exists in LO 5.3.1.1, OpenSUSE Leap 42.1 64bit rpm Linux.
Comment 12 QA Administrators 2018-06-26 02:43:49 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2020-06-26 03:41:20 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2022-06-27 03:29:12 UTC Comment hidden (obsolete)
Comment 15 Robert Großkopf 2022-06-27 10:21:58 UTC
Bug is still the same in LO 7.3.4.2 on OpenSUSE 15.3 64bit rpm Linux.