Description: when using the dragdrop-feature within tableview, the copying is working, but displayed is a wrong one until the view is closed an reopened. This happens within HSQL-ODB aswell as in FB-ODB Steps to Reproduce: 1.open any FB-table in table-view 2.select a record for being copied 3.drop it to the "+"-sign Actual Results: wrong record is shown but right record stored Expected Results: show right record after copying Reproducible: Always User Profile Reset: No Additional Info: - - -
Created attachment 176524 [details] example
oops - liked to edit my bugentry,as I mixed my test-files, but don't know how. So: This works fine with HSQL-odb, only FB-odb is faulty mh
Have tested this with internal Firebird. Took a table with autovalue for primary key. Will work as expected if I won't change a value for a primary key to a number, which is bigger than the next inserted ID. If I set the PK of one row to '222' and next inserted ID will be '9' it will show the row with PK 222 instead of the inserted content. You have to refresh the table to show the inserted value. All tested with LO 7.2.3.2 on OpenSUSE 15.2 64bit rpm Linux. Could be this bug has reported before - will have a look.
Dear mhonline, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug is still the same with Version: 25.2.3.1 (X86_64) / LibreOffice Community Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b 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
need to ceck your .odb form In a new .odb, new form with datagrid that show direct record of a table, the problem not occurs. Also, if drag a record directly in a Table, coping work fine. Check the Key field. Tested with Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 4; OS: Windows 7 Service Pack 1 X86_64 (6.1 build 7601); UI render: Skia/Raster; VCL: win Locale: it-IT (it_IT); UI: it-IT Calc: threaded
(In reply to mc from comment #6) > need to ceck your .odb form > > In a new .odb, new form with datagrid that show direct record of a table, > the problem not occurs. Has nothing do do with a form. Take any table with auto incremented value. Might look like this: ID Name 1 Robert 2 Bill 3 Claire ID is auto incremented. Change ID 2 to 20. Click on row with ID = 1 and move to end of the table. There will be sown as new row 20 Bill Refresh the table There will be shown 4 Robert This will appear only with Firebrid, not with HSQLDB. HSQLDB would insert the new row with 21 Robert
(In reply to Robert Großkopf from comment #7) > ... > 20 Bill > Refresh the table > There will be shown > 4 Robert > > This will appear only with Firebrid, not with HSQLDB. HSQLDB would insert > the new row with > 21 Robert ID Key in Firebird not work same as HSQLDB If you manually change value of ID Key in a table, need to update the internal ID "counter" before to continue to insert other record, ex. with: ALTER TABLE "table" ALTER COLUMN "ID" RESTART WITH 21; @mhonline first has showed a Form in attachment 176524 [details]
(In reply to mc from comment #8) > (In reply to Robert Großkopf from comment #7) > > ... > > 20 Bill > > Refresh the table > > There will be shown > > 4 Robert > > > > This will appear only with Firebrid, not with HSQLDB. HSQLDB would insert > > the new row with > > 21 Robert > > ID Key in Firebird not work same as HSQLDB > > If you manually change value of ID Key in a table, need to update the > internal ID "counter" before to continue to insert other record, ex. with: > ALTER TABLE "table" ALTER COLUMN "ID" RESTART WITH 21; > > @mhonline first has showed a Form in attachment 176524 [details] I know all this - have written the German original for Base Guide. But I isn't an argument while row wouldn't be refreshed and the inserted value will be shown in the right way for Firebird. There should be shown 4 Robert and not 20 Bill or, better, there should be found a way for Firebird to correct the autovalue to max ID, as ist works with HSQLDB, because the current behavior will run into an error if Firebird has counted ID should be '20' and primary key '20' is used for 20 Bill.