Bug 88032 - EDITING: Anomalies when copying field definition rows between tables in design view
Summary: EDITING: Anomalies when copying field definition rows between tables in desig...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 146542 (view as bug list)
Depends on:
Blocks: Paste Database-Tables
  Show dependency treegraph
 
Reported: 2015-01-05 00:05 UTC by James B. Byrne
Modified: 2024-01-04 16:02 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
LOBASE: simple base file showing results of table design cut and paste (4.55 KB, application/vnd.sun.xml.base)
2015-01-05 19:43 UTC, James B. Byrne
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James B. Byrne 2015-01-05 00:05:11 UTC
If one copies one or more table fields from a table design view and pastes them into a new table in design view then the comments are lost.

If the source field definitions have a custom date format then that format appears in the default value field in the destination table definition.

For example:

Source table
  Field Name            Field Type             Description

* date_effective_from   Date/Time[TIMESTAMP]   Date before which . . .

  date_effective_from   Date/Time[TIMESTAMP]   Date after which . . .

Entry required          No
Decimal places          0
Default value  
Format example          1900-01-01 00:00


Destination table after copy and paste before save
  Field Name            Field Type             Description

* date_effective_from   Date/Time[TIMESTAMP]   

  date_effective_from   Date/Time[TIMESTAMP]   

Entry required          No
Decimal places          0
Default value           1900-01-01 00:00
Format example          1900-01-01 00:0000


Destination table after save, exit, open and edit
  Field Name            Field Type             Description

* date_effective_from   Date/Time[TIMESTAMP]   

  date_effective_from   Date/Time[TIMESTAMP]   

Entry required          No
Decimal places          0
Default value           1900-01-05 00:00
Format example          1900-01-05 00:00

Note that in the design view of the new table each time that I click on the field type for either of these field the Default value and the Format example changes.  It apparently increments the day by 2 and the month will roll over if one repeats selecting and deselecting the Field Type a sufficient number of times.
Comment 1 James B. Byrne 2015-01-05 19:43:07 UTC
Created attachment 111780 [details]
LOBASE: simple base file showing results of table design cut and paste

This simple database design contains two tables, tbl_bugs and tbl_new_bugs.  tbl_bugs was created in design view and the manually entered design rows given descriptions.  tbl_new_bugs was also created in the design view but all of the design elements, other than the the primary key were copied from tbl_bugs and pasted in.

The results are that all of the descriptions are lost and the DATE/TIME[TIMESTAMP] fields are given default values that do not exist in the original table.

This particular database was created and modified entirely on a CentOS-6.6 Linux host.  It exhibits precisely the same behaviour as noted on OSX-10.9.5.
Comment 2 raal 2015-01-08 08:04:46 UTC
I can confirm with LO 4.3.5, win7.
In my case is 

Destination table after save, exit, open and edit
  Field Name            Field Type             Description

* date_effective_from   Date/Time[TIMESTAMP]   

  date_effective_from   Date/Time[TIMESTAMP]   

Entry required          No
Decimal places          0
Default value           1900-01-03 00:00
Format example          1900-01-03 00:00
Comment 3 QA Administrators 2016-01-17 20:03:42 UTC Comment hidden (obsolete)
Comment 4 James B. Byrne 2016-01-18 14:04:41 UTC
This bug is still present in v.5.0.3.2 which is the latest that I have available for CentOS-6.7.
Comment 5 QA Administrators 2017-03-06 14:13:54 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2019-12-03 14:28:37 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2021-12-03 04:33:36 UTC Comment hidden (obsolete)
Comment 8 Alex Thurgood 2022-01-03 13:40:02 UTC
*** Bug 146542 has been marked as a duplicate of this bug. ***
Comment 9 Alex Thurgood 2022-01-03 13:43:42 UTC
As indicated in the duplicate bug report 146542, this bug is still alive and well in LibreOffice 7.3.0.1

Version: 7.3.0.1 (x64) / LibreOffice Community
Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-GB
Calc: threaded
Comment 10 QA Administrators 2024-01-04 03:13:07 UTC Comment hidden (obsolete)
Comment 11 James B. Byrne 2024-01-04 16:02:24 UTC
Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 60(Build:1)
CPU threads: 16; OS: FreeBSD 13.2; UI render: default; VCL: qt5 (cairo+xcb)
Locale: en-CA (C.UTF-8); UI: en-US
Calc: threaded

Problem remains in this version.