Bug 128965 - Error: Database connection failed when opening. Database has lost ALL information.
Summary: Error: Database connection failed when opening. Database has lost ALL informa...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.2.7.1 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-22 13:25 UTC by Ronald
Modified: 2020-04-16 13:53 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
error message of lost database (33.27 KB, image/jpeg)
2019-12-21 09:32 UTC, Ronald
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ronald 2019-11-22 13:25:00 UTC
Description:
I use a database to merge data with a document (invoices and customer data). If you do not close all windows of LibreOffice, after a couple of days the datase looses ALL information and a connection is not possible. You need to restore a backup to continue. This is very annoying, because all entered data since the last backup is lost. I used OpenOffice before and this had the same problem. I was hoping LO is more stable.

Steps to Reproduce:
1. Open a document that has a connection to a database
2. Enter info in database
3. Merge with document and save or close document
4. Leave it for a couple of days and at some time if you open the document and connect to database if fails (in my case)

Actual Results:
The database has lost all of its information (data) and is empty.

Expected Results:
You get an error saying that a connection is not possible and some info, but I do not have it at this time


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
The software should not loose its information over time. Something cause the database to get corrupt and drops all contents.

Versie: 6.2.7.1 (x64)
Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf
CPU-threads: 6; Besturingssysteem: Windows 10.0; UI-render: GL; VCL: win; 
Locale: nl-NL (nl_NL); UI-taal: nl-NL
Calc: threaded
Comment 1 Alex Thurgood 2019-11-22 14:46:47 UTC
@Ronald : please provide :

- type of database connection and any driver used to connect ;
- database version if external connection (e.g. server) ;

- more precise indications of how long the connection is maintained before it is dropped, for example, is there a server setting that defines an auto-disconnect ;

- whether or not your network connection is stable and not subject to drop outs.


Only in this context can we help identify whether the problem is with LibreOffice or perhaps lies elsewhere.
Comment 2 Alex Thurgood 2019-11-22 14:52:05 UTC
You might want to read the following bug issues which could be related :

bug 88796
Comment 3 Ronald 2019-11-22 22:23:36 UTC
- database connection: through java, no msql server

- connection is alive for days or a week, no specific time

- database now is on the internal network (NAS), but in previous situations on the same harddrive as LibreOffice
Comment 4 QA Administrators 2019-11-23 03:44:26 UTC Comment hidden (obsolete)
Comment 5 Alex Thurgood 2019-11-25 07:32:33 UTC
@Ronald : Unfortunately, still not enough information.

When you write "database connection through Java", what do you mean ?

What kind of ODB file are you using ?

- embedded HSQLDB ?
- some other kind of JavaDB ?
- some other kind of DB engine with a Java driver (JDBC) ?

If we are talking about the default embedded hsqldb engine in an ODB file, then moving the ODB file to a NAS will inevitably cause a connection timeout if, for whatever reason, your Windows OS or your NAS drops the network connection, for example, to save energy, or when one or the other go to sleep...

In that case, you should be reading the HSQLDB documentation for version 1.8.0 to see if there is a parameter that you can include in either the PROPERTIES file or the SCRIPT file that should be present in the ODB file (which is a type of zip container).

Resetting to NEEDINFO pending requested information.
Comment 6 Ronald 2019-11-26 10:26:10 UTC
It is the embedded version.

I have moved the (data) files from the NAS to the PC where LibreOffice resides.
And I moved to LO version 6.3.3.2

Let's see if this resolves the problem.
If not I'll make a screenshot of the error message and report it here.
Comment 7 Alex Thurgood 2019-11-26 10:55:33 UTC
@Ronal : thanks, resetting back to unconfirmed.

The general functioning of embedded hsqldb in an ODB file is that any data changes not flushed to the hsqldb instance will potentially be lost if the connection is lost. As the ODB file only loads some of the data from the recordset into RAM, and the newly modified data forms part of that volatile memory space, any connection drop or cut out will potentially lead to data loss. Some of that might be recoverable from a lock file (LCK) that LO creates when opening an ODB file with embedded hsqldb database. However, the data in the lock file may or may not be exploitable, and in theory will disappear if the ODB file is closed cleanly. Any data that was transiting in the network layer will likely equally be lost if you are acessing the file over a network.
Comment 8 Ronald 2019-12-21 09:32:57 UTC
Created attachment 156716 [details]
error message of lost database
Comment 9 Robert Großkopf 2019-12-21 10:04:50 UTC
The error-message says: It couldn't execute the script-file inside the *.odb-file.

Copy the *.odb-file and try to repair the script-file:
If you open the *.odb-file with a packing-program (zip) you could see a folder database and inside this folder the script-file.
Try to open this file and have a look at the entries.

The data aren't inside the script-file. But without the definition of the tables in this file you can't have a look at the data, which will be in the file database/data.
Comment 10 Ronald 2019-12-21 13:50:30 UTC
Hi,

The script file is okay. But the data file is empty!!
That is the big problem, all your data is gone forever. Thank you.

ron
Comment 11 Robert Großkopf 2019-12-21 16:27:47 UTC
(In reply to Ronald from comment #10)
> Hi,
> 
> The script file is okay. But the data file is empty!!
> That is the big problem, all your data is gone forever. Thank you.
> 
> ron

Is there any content in database/backup-file? The content of backup will be loaded when the parameter "modified" will be changed from "no" to "yes" in database/properties.
Comment 12 Ronald 2019-12-21 16:57:52 UTC
Wow, that was a golden tip! I wish I knew this before all these years.
I did what you wrote and the database was back.
Thanks a million.

Now back to the problem: whay does this happen and to prevent this?

ron
Comment 13 Robert Großkopf 2019-12-21 18:38:43 UTC
(In reply to Ronald from comment #12)
 
> Now back to the problem: whay does this happen and to prevent this?
> 
Problem with the internal HSQLDB is: It will be unzipped when opening the database And will be wrote back to the file while closing the database. If there is any problem when closing the database the content of the database-file wouldn't be complete.

I have written a macro for this and put it in the Base Handbook (German Version you could get here: https://de.libreoffice.org/get-help/documentation/
If you connect the macro directly to opening of the base-file a backup will be made automatically.

If you will use Base for professional databases I would prefer a database-server and connect with Base to the server-database. It could be HSQLDB, but also something like MariaDB/MySQL or PostgreSQL.

You could also connect to an external HSQLDB without using a server. The data-file mustn't be zipped when closing the Base-file. Would be a saver solution than the internal HSQLDB. I have described this also in the Base Handbook.
Comment 14 Robert Großkopf 2019-12-21 18:40:21 UTC
We couldn't solve this special problem, because we don't know how to reproduce this. Should we set this bug to RESOLVED and WORKSFORME?
Comment 15 Ronald 2019-12-21 20:26:59 UTC
The main thing is, I have my data back and I know now what to in case it happens again (and it will happen again).
So yes, set this bug to RESOLVED and WORKSFORME.

In the maen time I will study the Base Handbook and see if I can use a different, more safe way, to use a database.

Thanks all.
Comment 16 Robert Großkopf 2019-12-22 07:53:50 UTC
I will set this one to resolved and worksforme. See comment 14 and 15.
Comment 17 Jason peters 2020-04-16 13:53:31 UTC
If you feel that your data is not protected enough, then you should go to the Azure marketplace and get this tool https://azuremarketplace.microsoft.com/en-us/marketplace/apps/spinbackupinc.sb4w-o366. It gave me the protection that I needed.