OK so while I appreciate the folks who do the work on this project, disappointed isnt even the right word. I have now had 2 db’s go to zero bytes after not saving the last edit to a form and then closing normally the program. Using Linux Mint and 24.8 and no tmp odb files in the tmp directory. Attempting to open the odb files with archive manager does not work either. Very perplexed as to 1. How the hell this happens after having saved the file plenty of times and 2. Also need to figure out how to submit a bug report for another issue where when moving a form inside a subform is a guaranteed crash. Any assistance in recovering the db would be greatly appreciated as im beyond disappointed with this software. Thanks.
1 Like
Shouldve asked but if there not a dump of sorts to be able to post from the program itself that would be helpful in tracing the bugs?
For a bug description:
Try to reproduce the bug.
Write step by step what to do to reproduce the bug.
Add the LO-version you are using (copied from help → about LibreOffice).
You are using Linux Mint. So the version could be a version special packed for Linux mint, not a version packed original by LibreOffice. There are some special behaviors of Base when packed by Linux distribution. Sometimes it doesn’t install Base by default, then ReportBuilder is missing, then reports won’t work…
build: 0f794b6e29741098670a3b95d60478a65d05ef13
There is some further detail on how to report bugs on this Wiki page which may help you.
Hint; click the icon next to Version Information and all the required data will be put in your clipboard so you can simply paste it here, or wherever. For example, mine:
Version: 24.8.2.1 (X86_64) / LibreOffice Community
Build ID: 480(Build:1)
CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: x11
Locale: en-AU (wbp_AU.UTF-8); UI: en-US
SlackBuild for 24.8.2 by Eric Hameleers
Calc: threaded
Version: 24.8.2.1 (X86_64) / LibreOffice Community
Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13
CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded
So – guessing that because its a flatpak which im thinking is exclusive to mint, that could be the issue?
Build ID is an ID, which isn’t used for packages from a distribution. Packages from a Linux distribution is very short. But I don#t know anything about Flatpak…
Now try to reproduce the bug with a new created database. Have a look which database you use: Internal HSQLDB, internal Firebird or a connection to any external data source.
I know the db’s are hsqldb.
Now try to reproduce. I did this: Opened a HSQLDB-database. Created a form, but didn’t save the form. While window for form is open I closed the Base file. Closed also LO, reopened the Base file. Form isn’t there (because it isn’t saved), but tables are there. No 0-Byte-file.
Recommendation: Avoid embedded databases for “productive” work. The embedded data has to be extracted on opening and re-packed on close. Usually this works, but it is a rost , if anything happens during closing the file. Typical problem is for example just closing the lid of a laptop and having an empty battery befor one restarts…
@skyandrews : Please read the title of this thread: 0 bytes → there is nothing you could do with such a database file.
Seems you never worked with LibreOffice database files: The fist action is creating this file and save it in you system. Then you could start to create a table or something else. And such a created database file has ca. 2,3 kB, never 0 kB.
This is the default triage to open a document when LibreOffice couldn’t read the mimetype in the document. And a 0 kB file won’t have any mimetype information.
That’s another thing about LO I did not know…! Thank you! I had a flight instructor who used to tell me: “The day you fail to learn something new about flying is the day you better stop!” I will apply that here.