Description: Although the clipboard content was changed, LO Base keeps inserting the old out-of-date clipboard content which was current, when the program (Base) was started. Steps to Reproduce: 1. Have an .odb file ready to quickly branch into a pre-setup database with LO base 2. Open a .xlsx file with lets say a basic table as simple as 1 column with a heading and some data below 3. copy the full data area (including header in my case but that doesnt matter) 4. open base (using the mentioned .odb file in my case) 5. insert your clipboard content to a suited database, check the db content with a double click 6. change the data in calc, save, copy to clipboard again 7. go to base again and insert the "new" clipboard content to the same file Actual Results: The same old clipboard content that was current when base was started gets inserted to the database again. Expected Results: The new clipboard content should be inserted. That the clipboard actually contains new data can be seen if the insert is done to any other programm let it be notepad or word or whatever. Reproducible: Always User Profile Reset: No Additional Info: My guess would be that base somehow reads out the clipboard when it is started, saves the content to another data structure and furthermore no longer checks if the clipboard was updated. Problem can be worked around by closing base and starting it again AFTER the clipboard content was changed. Then the new content gets inserted, but again, as soon as its changed the new content is ignored. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Please attach test documents, so time is not spent on creating them for every tester. Also a more exact description of step 5 would be good. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the documents.
Couldn't confirm any buggy behavior here: Opened Calc and created a little table with names and ID (for primarykey). Copied the table to clipbord and inserted it to an already open Base-file. Works as expected. Then changed the ID for every field to new IDs and changed the other content. Added the content with "add data" to the table. Isn't shown directly, but after refreshing the table the GUI shows the new rows also. So no bug on OpenSUSE 42.2 Version: 5.4.4.2 Build-ID: 2524958677847fb3bb44820e40380acbe820f960 CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
(In reply to Buovjaga from comment #1) > Please attach test documents, so time is not spent on creating them for > every tester. Also a more exact description of step 5 would be good. > > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the documents. a test document would be rather useless, as i wrote it can be as simple as: |field1| field2| |1 | a |1 | b |1 | c but i can attach this if this saves you time. But i cant attach a macro that changes all the one's to two's, thats something that needs to be done by hand. I also cant attach a pre-made .odb file as i cant know what database is on your system and what tables this contains, and what driver this requires and what login data this needs. Hope you understand.
Created attachment 138493 [details] basic test file
(In reply to robert from comment #2) > Couldn't confirm any buggy behavior here: > Opened Calc and created a little table with names and ID (for primarykey). > Copied the table to clipbord and inserted it to an already open Base-file. > Works as expected. > Then changed the ID for every field to new IDs and changed the other > content. Added the content with "add data" to the table. Isn't shown > directly, but after refreshing the table the GUI shows the new rows also. > > So no bug on OpenSUSE 42.2 > Version: 5.4.4.2 > Build-ID: 2524958677847fb3bb44820e40380acbe820f960 > CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4; > Gebietsschema: de-DE (de_DE.UTF-8); Calc: group nice to hear that this behaviour doenst appear in version 5.4.4.2 under Linux (i reported it for 5.4.3.2 / Windows) i will test the new version and give feedback.
A test-document would be something like an empty internal Database (with or without table) and a spreadsheet-file. Content of your spreadsheet-file couldn't be added to a table without special description: Where is the primarykey? Could only be field 2, because field 1 has all the same content. Or is it created automatically by another (unnamed) field? What should be changed for second input? Must be all the content of field 2, if this field contents the primarykey. Must be only one field, if primarykey is created automatically. Only one field to have a look if content of clipboard will be recognized or not.
(In reply to robert from comment #6) > A test-document would be something like an empty internal Database (with or > without table) and a spreadsheet-file. > > Content of your spreadsheet-file couldn't be added to a table without > special description: > Where is the primarykey? Could only be field 2, because field 1 has all the > same content. Or is it created automatically by another (unnamed) field? > What should be changed for second input? Must be all the content of field 2, > if this field contents the primarykey. Must be only one field, if primarykey > is created automatically. Only one field to have a look if content of > clipboard will be recognized or not. why should there be a primary key? I add all my data to an IBM Power i DB2 Database connected via ODBC, and there is no need for a primary key in the initial dataset in the classical way, IBM's DB2 handles this internally by assigning each incoming record a record number rrn(). So i could just add 1 billion lines containing just a 1 as the only field and it would be fine. But when i change this 1 (in calc) to let's say a 2, it is not fine if LibreOffice base keeps adding ones after i copied the new data content. All this worked fine with release 5.3, the problem appeared with version 5.4 and it's a highly critical killer bug for us. Thanks for your efforts going into the details here but i will first try to validate roberts input and check out if this bug was already fixed with 5.4.4
Like Robert said: "A test-document would be something like an empty internal Database (with or without table) and a spreadsheet-file" So forget the IBM db for now and try to reproduce it with an HSQLDB document. Otherwise we cannot confirm there is a bug.
bug fixed in 5.4.4.2