Description: Sometimes, I need to change part of a query, or a form. This change needs to be saved by saving the entire database file. Mostly, I don't remember this, until I am finished with the work on the database. However, I get reminded almost instantaneously, that I should have done it: it takes several minutes, until the result of a query is eventually displayed, and it takes equally long, to close the window. The more actions I do without having saved the database file, the longer it takes to finish a task within the database. In some cases it was impossible to close the window. The database is not very big, it has around 20 tables, the biggest of which has 500 entries, each with about 20 to 30 fields, the others are hardly ever used. There are about 50 queries and 24 reports. Finally, there are 7 forms. The entire database file is about 1.2 MB in size. I have observed this for years and always forgot to report it... Steps to Reproduce: 1. Open a database file 2. Make a change to a query. Do *not* save the change to the database file! 3. display the query or a form or report and do some work on them. 4. repeat this with other queries, forms or reports Actual Results: You should notice an increasing lag. Expected Results: It should continue to work at the same pace as usual. Remedy: save the database file (if you get back to do it) Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: de Module: OfficeDatabaseDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Which version of LO do you use: The packages from your Linux distribution or the packages directly from LO? Which database do you use: Internal HSQLDB, internal Firebird or something else? Would be good to get an example database here. I can't reproduce this behavior with my databases.
Sorry for the delay... it's the version from the distribution (Manjaro, KDE). I do all upgrades regularly, but this behaviour I have witnessed for years, even after a complete new installation with new user etc. I should have reported it earlier. Database is HSQLDB, I guess. I haven't done any changes to the settings. Where would I find info about what engine is being used? I can't send you a sample, because the database contains private information. I would need to set up a new database. That may take time, since I have other things to finish first.
(In reply to Dr. Martinus from comment #2) > it's the version from the distribution (Manjaro, KDE). I have never worked with this system. Is it possible to install a *.deb or *.rpm package on this system? You should try to install the original packages from LO so we could see if it is a bug from LO. In other Linux distributions you could install packaged from LO parallel to the version from the distribution. Have installed here many different *.rpm-versions (OpenSUSE). If it is impossible to install a package direct from LO: File a bug to Manjaro.
(In reply to Robert Großkopf from comment #3) > I have never worked with this system. Is it possible to install a *.deb or > *.rpm package on this system? You should try to install the original > packages from LO so we could see if it is a bug from LO. In other Linux > distributions you could install packaged from LO parallel to the version > from the distribution. Have installed here many different *.rpm-versions > (OpenSUSE). rpm or deb can be installed on Manjaro/Arch systems, but that would only go with a workaround, and I don't really feel confident to do that. Installing LO directly from the LO-website has always become trying for me (because it's split in multiple packages and one depends on another and I get always errors because of that). And as far as I know, there are no packages for Arch/Manjaro distribution available, so it would become even more difficult. > If it is impossible to install a package direct from LO: File a bug to > Manjaro. And they will tell me to report to LO. I had this problem already long before I switched to Manjaro. So I don't think it's related to the distribution.
(In reply to Dr. Martinus from comment #4) > > And they will tell me to report to LO. I had this problem already long > before I switched to Manjaro. So I don't think it's related to the > distribution. If you couldn't try with original packages and nobody could see the same buggy behavior with original packages it will be impossible to help here. I couldn't confirm the behavior while closing a Base file with an unsaved query. There will appear a message the query hasn't been saved. I will press "Yes". Then another message appears if I want to save the changed database file. I press "Yes" and the database has been closed without any delay. I don't know what other distributions will do while creating packages. But there are Base bugs in openSUSE version (rpm) and identical in Ubuntu version (deb) but this bugs won't appear in the original, which is available as *.deb or *.rpm and could be installed parallel to this versions on the same system.
I could easily test this in a matching system (Arch & KDE), but I need an example file that is proven to display the slowness in your system. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
I can't give you a database which contains highly sensitive, protected data. I don't have any other. I consider creating a new one for that purppose, with random data, but that may take time.
I just realise that I don't use LO any more because I had serious problems relating to printing documents with graphics - LO just stopped printing at the page where the graphics were (on every document, no matter what kind of graphic there was). Hence I changed to the alternative AOO, where this works flawlessly. This makes it even more unlikely that I create a new database which would match more or less the ones with which I have problems.
(In reply to Robert Großkopf from comment #5) > I > couldn't confirm the behavior while closing a Base file with an unsaved > query. There will appear a message the query hasn't been saved. I will press > "Yes". Then another message appears if I want to save the changed database > file. I press "Yes" and the database has been closed without any delay. Well, that isn't the problem. The problem starts if you keep on working with the database *without* saving it, after you have made alterations to reports or forms or queries. Adding a few entries or editing some, and eventually LO will just stop working. That's what I experienced and reported.
(In reply to Dr. Martinus from comment #8) > I just realise that I don't use LO any more because I had serious problems > relating to printing documents with graphics - LO just stopped printing at > the page where the graphics were (on every document, no matter what kind of > graphic there was). Hence I changed to the alternative AOO, where this works > flawlessly. This makes it even more unlikely that I create a new database > which would match more or less the ones with which I have problems. It would be nice, if you reported the printing issue. New bugs can be bisected and the causing commit found exactly. Possibly the same could be done to this slowness issue, if we only got an example file to test with.
Dear Dr. Martinus, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Dr. Martinus, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp