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
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
Did this ever work properly in earlier versions, i.e. is it a regression ?
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…)
Resolve with a SQL statement, ex.: alter table "tbl_Rechnung" alter "ID" position 1 Close all and reopen .odb, copy&paste to calc and it work fine. Probably an isolated problem with your file, but I think the internal LO function that creates the ID field has some problem, in fact to avoid problems I create the tables via SQL command.
(In reply to mc from comment #4) > Resolve with a SQL statement, ex.: alter table "tbl_Rechnung" alter "ID" > position 1 > Close all and reopen .odb, copy&paste to calc and it work fine. > > Probably an isolated problem with your file, but I think the internal LO > function that creates the ID field has some problem, in fact to avoid > problems I create the tables via SQL command. No, isn't an isolated problem of my file. I have seen this in a videocall for a database another people created: 2 Tables couldn't be copied the normal way, because the field position had been destroyed. This tables also had many fields. I have also tried to set the position through SQL, but when closing the file and opening it again it is the same buggy behavior. Remember: Firebird had saved the right position. It will be shown by the query I added for every table: Field position of Firebird and position when trying to edit the table or copying the table to Calc will differ.
Created attachment 202570 [details] table after statement to alter position of ID field See the difference of DDL on original table and before altered the ID field position
(In reply to mc from comment #4) > Resolve with a SQL statement, ex.: alter table "tbl_Rechnung" alter "ID" > position 1 > Close all and reopen .odb, copy&paste to calc and it work fine. > > Probably an isolated problem with your file, but I think the internal LO > function that creates the ID field has some problem, in fact to avoid > problems I create the tables via SQL command. That is only a workaround once the problem has been detected. The fact is that if a user has created their tables, as the majority of users do, via the UI, then the corresponding table thus created shouldn't lead to a problem when copy/pasting to Calc. Telling users to create their fields using SQL DDL is not the solution. The whole point is that the user has a legitimate expectation that the UI produces a table with a valid field order, or that that field order is respected by the copy/paste mechanism.
That's correct. The problem most likely lies in the code for the table creation interface. Hopefully, they'll improve its usability soon.