Description: After opening the report the table stay in use and it is impossible to delete without reopening the odb file. Error mesage: firebird_sdbc error: *unsuccessful metadata update *object TABLE "test2" is in use caused by 'DROP TABLE"test2"' Steps to Reproduce: 1.create an odb file with firebird embedded 2.create a table 3.create a report based on the table 4.open the report 5.close the report 6.try to delete the table of the report Actual Results: Deleting the table of the report is impossible Error mesage: firebird_sdbc error: *unsuccessful metadata update *object TABLE "table" is in use caused by 'DROP TABLE"table"' Expected Results: table deleted Reproducible: Always User Profile Reset: No Additional Info: Error mesage: firebird_sdbc error: *unsuccessful metadata update *object TABLE "table" is in use caused by 'DROP TABLE"table"'
Working with a local build of commit 38b1497d (2020-11-04), built and running on debian-buster, I have created the reported problem. My error message carries the additional information: /home/terry/lo_hacking/git/libo6/connectivity/source/drivers/firebird/Util.cxx:68 Further observations: (*) The problem persists if the .odb is saved and reopened between steps 3 and 4. (*) If the saved .odb is opened there is no problem deleting the table without steps 4 and 5. Bug 128518 also reports the inability to delete a table from an embedded Firebird database, but I am confirming the present bug because: (*) That bug was closed a year ago. (*) The difficulty in that bug followed editing the table. There was no report involved. (*) Commenters on that bug got varying results. This bug does not (yet) have that complication. I see it as wrong that LibreOffice relies (even accidentally) upon previous execution of the report when it allows or disallows deletion of the table. I do not have an opinion on whether LibreOffice should allow deletion of that table while a referencing report exists. But if deletion is disallowed, the error message should say why, and LO need not attempt the deletion at all. I am adding keyword needsUXEval. If, after deleting successfully deleting table, you run the report anyway, the resulting error message is impolite. I have reported this as bug 138241.
This buggy behavior has nothing to do with https://bugs.documentfoundation.org/show_bug.cgi?id=128518 There had been reported deleting of the table is impossible. No error, no warning, nothing to do with the report. In this case it seems opening the report says to Firebird: Table is needed. But closing the report doesn't free the table. You have to close the connection to Firebird by reloading the database file. Then you could delete the table.
With Hsqlbd embbeded, LibreOffice allows deletion even after opening the report. It would be better to allow deletion with Firebird embbeded also?
If deletion is not possible I suggest to show a confirmation box and explain what causes the misanticipation. => needsdevadvice
Dear ablogic, 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
Still the same buggy behavior with LO 7.4.3.2 on OpenSUSE 15.3 64bit rpm Linux.