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

See Also:
Crash report or crash signature:
Regression By:

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
Describes, how to reproduce the bug. (67.35 KB, application/vnd.oasis.opendocument.graphics)
2013-01-22 19:41 UTC, Robert Großkopf

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
Build: 165a79a-7059095-e13bb37-fef39a4-9503d18
OS: Windows 7 Home Premium (32-bit).

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:
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, OpenSUSE 42.1 Leap, 64bit rpm Linux.
Comment 9 walkerkorea 2016-01-21 19:43:27 UTC
Tested LO, Windows 10.

My original post was muddled, I'm afraid, but a bug still exists in, 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, 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
Dear walkerkorea,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team