Description: I just had opened a database which I am using for many years now. I have had the problem that, when editing a form or some other things in the database (not editing data entries, but changing the structure of the database in some way), the database becomes slower and slower up to the point that it cannot be saved, because the process of saving it would take hours (more than two or three). In many cases, I had to shut down LO forcefully because I needed to work on other things and couldn't go on waiting for the saving process to finish. Today there was again such an issue: I had added three boolean fields to the database table and wanted to add them to the form which I use regularly. While adding the three boolean fields to the form went more or less smoothly (it started lagging already, but I got all three fields to the position where I wanted them to be), the saving didn't. After I noticed that Base started lagging again, I immediately hit the save button in order to save the form and then the database (which is also required). However, nothing happened except that LO froze. I waited for an hour and observed during that time, that LO was using CPU power and writing to disk at some point of time, but I didn't see a temporary file being created or anything else. The database has a file size of 1.2 MB, but the memory consumption of LO went up from 1.6 GB to 2.4 GB within a few minutes, and after an hour or so it crashed (there was still enough RAM available (About 10 GB), so that couldn't have been the reason). After reopening and recovering the database, the database file had a size of about 20 kB, i.e. all data was lost. Luckily I save every day a copy of the file using a script, usually when the PC is being started, because after having experienced that problem every now and then (lets say once in a year, maybe more often), I knew that it can happen any time, and if there is no recent backup, I would have to reconstruct a database with about 400 entries, each having about 30 to 40 fields. Quintessence: Editing the database structure is virtually impossible. I have observed this behavior for many years, and I guess I have reported it previously, but couldn't find the report. So I apologize if this is a duplicate. Unfortunately, I cannot send you the database in question, because it contains highly sensitive data. And another thing: I just tried doing changes in a limited number (maximum 3), and it worked fine (after each edit save and close the databes, then open it again and doing the next edit and so on). But when there are more edits in a row, it gets stuck after a while, LO doesn't respond as quickly as it usually does and saving becomes impossible. Steps to Reproduce: 1. Open a database 2. Change structure of the database, add fields and/or change layout of a form, etc. 3. save the file Actual Results: LibreOffice won't save it, but take a very long time and eventually crashes, losing all data in the database. Expected Results: The database is being saved with all changes that have been made. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: de Module: OfficeDatabaseDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes Additional info: Operating System: Manjaro Linux KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.6.62-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 2600 Six-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 570 Series Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B79 System Version: 1.0
Which database type do you use? Internal HSQLDB? Which version of Java did you install? Which version of LibreOffice do you use? Have never seen such a buggy behavior with OpenSUSE 15.6 64bit rpm Linux Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 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
HSQLDB is the database type "java --version" gives the following: openjdk 11.0.25 2024-10-15 OpenJDK Runtime Environment (build 11.0.25+9) OpenJDK 64-Bit Server VM (build 11.0.25+9, mixed mode) LO version 24.2.7.2 (s.above)
I think this is the best answer. HSQLDB is the database type "java --version" gives the following: openjdk 11.0.25 2024-10-15 OpenJDK Runtime Environment (build 11.0.25+9) OpenJDK 64-Bit Server VM (build 11.0.25+9, mixed mode) https://io-games.onl/
(In reply to Dr. Martinus from comment #2) > HSQLDB is the database type > > "java --version" gives the following: > > openjdk 11.0.25 2024-10-15 > OpenJDK Runtime Environment (build 11.0.25+9) > OpenJDK 64-Bit Server VM (build 11.0.25+9, mixed mode) > > LO version 24.2.7.2 (s.above) Java is the same here, but special package of OpenSUSE. Missing the build ID of your LO-version. There are differences between original versions of LibreOffice (very long build ID) and the versions included. Have tested here with a DB internal HSQLDB, 1,5MB, only one table, 30000 rows, 15 columns. No problem with slowing down. Move to last record in about 4 seconds. Had been much slower in the past - depending of version of LO and version of Java.
(In reply to Robert Großkopf from comment #4) > Missing the build ID of your LO-version. There are differences between > original versions of LibreOffice (very long build ID) and the versions > included. Please copy and paste here the content of your Help - About by clicking the copy button. This allows us to know more about your system. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.