Bug 168012 - FIREBIRD: Fieldposition totally destroyed when copying table with many fields
Summary: FIREBIRD: Fieldposition totally destroyed when copying table with many fields
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1 all versions
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: dataLoss
Depends on:
Blocks: Database-Firebird-Default
  Show dependency treegraph
 
Reported: 2025-08-19 14:41 UTC by Robert Großkopf
Modified: 2025-08-28 14:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Copy table "tbl_Rechnung" to Calc. Then open "tbl_Rechnung". Have a look at the fields in both tables. (357.07 KB, application/vnd.oasis.opendocument.database)
2025-08-19 14:41 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2025-08-19 14:41:01 UTC
Created attachment 202381 [details]
Copy table "tbl_Rechnung" to Calc. Then open "tbl_Rechnung". Have a look at the fields in both tables.

Open the attached database.

Right mouse click of one of the tables, example "tbl_Rechnung".
Copy table.
Open an empty Calc document.
Insert content.
Fields will be shown with following order:
"MailVersendet", "ID", "Kunde_ID", "Mitarbeiter_ID", "Datum" …
but the content, which will be shown in the columns differ:
"Datum" is shown in column "Mitarbeiter_ID", "ID" is shown in "MailVersendet" …
Open the same table with left mouse click in Base. It will show the right order of fields and the right entries.
You could see the wrong fieldposition also when opening the table for editing, not for input data. "MailVersendet" will be shown as first field.
Now execute the query "qry_Fieldposition_tbl_Rechnung". Will show the saved position in the database. This position is used when opening the table for input data. 

Same behavior in "tbl_Firma", where the field for the first position ("ID", position 0) will be shown in position near '50'!

This only happens for tables with many fields like 32 fields for "tbl_Rechnung".
Don't know if this bug also appears with internal HSQLDB. Have first seen this in internal Firebird.

This bug will be a nightmare for people, who want to copy tables from one database to another.

Appears under
Version: 25.8.0.4 (X86_64)
Build ID: 48f00303701489684e67c38c28aff00cd5929e67
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

but also older version. 
Have seen this also when helping other people through videocall copying data from one database to another
Comment 1 Alex Thurgood 2025-08-20 08:17:10 UTC
I can reproduce this also with

Version: 25.2.4.3 (AARCH64) / LibreOffice Community
Build ID: 33e196637044ead23f5c3226cde09b47731f7e27
CPU threads: 8; OS: macOS 15.6; UI render: Skia/Raster; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded
Comment 2 Alex Thurgood 2025-08-20 08:21:32 UTC
Did this ever work properly in earlier versions, i.e. is it a regression ?
Comment 3 Robert Großkopf 2025-08-20 09:28:45 UTC
Tested also in Version: 7.4.7.2 / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

Also in
Version: 6.1.5.2
Build-ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU-Threads: 6; BS: Linux 6.4; UI-Render: Standard; VCL: gtk2; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded

Same buggy behavior. So I don't think it's a regression.

Note: If I drag the table from Base file to a Calc table and drop it there the field position will be right. Drag and drop seems to work, copy doesen't work right. Drag and drop seems to get the same data as the table opened for input data in GUI, while copy will get the data as a mix from table opened for editing/adding/deleting fields. And the position in this editor isn't the same as the position for the data (and isn't the same as the position saved in the database…)