7.2 Base/Firebird Possible Problem

English
#1

Windows 10 Latest
LO 7.2.0 and 7.2.1, Firebird embedded

Base table with about 370 records and 25 fields
Conversion from embedded HSQLDB was done a number of versions ago with no major problems.
Everything ran fine (as far as I can tell) through version 7.1.5.

Updated to 7.2.0 and now have problems with relatively simple queries that no longer run, or run super slow and return garbage entries and/or missing records. Mailmerge using queries experience the same thing.

A search of recent changes and bug reports does not bring up anything similar.
I am at a loss of even how to describe the problem or set up the failing conditions.
I am pretty sure (but not positive) that it is not a table problem since it has been running fine up to 7.2.

Was there by any chance a Firebird change in 7.2 ?

Anybody else experiencing Base query problem in 7.2 ?

Here is a test file and a picture of results. I went to Tables and opened Newpersonalinfo. Selected the Zip column and tried to sort A-Z. After a long time of appearing to be hung up, the result was a messed up sort.

Table Sort on Zip
Table Sort on Zip1097×370 35.5 KB

#2

Hello,

Current version of Firebird embedded is 3.0.7 but not certain when it was implemented in LO. Do not see note in 7.2.x release for it. Don’t see any issues on my end with:

Version: 7.2.1.2 / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

However do not use it much more than testing for issues here.

May be best to post a sample with a problem query.

Edit:

Not clear but maybe implemented through tdf#134526

#3

There must have been something changed from 7.1 to 7.2. See bug 144163. But there is nothing reported about slow queries …

#4

Thanks for the reply. I am a little disappointed with Base (or embedded Firebird) at this point since things appeared to be running pretty smoothly after the lengthy time it took to get Firebird initially implemented. I am in kind of a quandary about what is the path forward. Should I patiently wait for a better running version (and miss out on other LO updates) or start looking for a different database solution? I am not a coding type person so a Calc solution with heavy use of macros is not very inviting. Any suggestions for a old semi-technical person?

#5

If you are trying to open the table, not a query: Seems it to be slow also? I have just tested with a database with 10 fields and 9000 columns. Runs pretty here with internal Firebird on OpenSUSE with LO 7.2.2.1.

Have converted also a database with 15 columns and 30000 rows to Firebird. No problem with a simple query like SELECT * FROM "Table" here. You could try it with this database: Firebird database 15 columns, 30000 rows

Could you add an example, which is running slow? Not the original data, only 25 fields with the same kind of field type of your original and dummydata, created in Calc for example.

#6

Requires opinion. You need to make your own decision on this. But then again, not certain of your problem as I cannot reproduce. Have asked for sample but nothing yet. Want help, post a sample.

#7

Seems there is a problem with UTF-8 or something else. The signs in your screenshot doesn’t show numbers. I have downloaded the file, opened the table and sorted … no problem in LO 7.2.2.2 and also LO 6.4.7.2.

One hint: Be careful with that file. There is also the whole HSQLDB inside the file. The data, which are shown in the only table, couldn’t be all data of a file with over 5 MB.

#9

Thank you very much for looking into this mystery.
I will download and test with LO 7.2.2.2 when it is released.
Also thank you for the warning about other data in the file. I built this example from the original file and deleted all the other items, I thought. I don’t understand the file structure but I think I have backups of anything needed.

#11

I tested with the pre-release version of 7.2.2.2 and it looks like my problem is resolved! HOORAY!
Checking the list of corrections, there were a few that seemed to relate.

#12

Nevertheless, this is an embedded database. You need a tight backup strategy to protect yourself against data loss.

#13

You are right, but in my personal experience with Firebird, mainly with not embedded database, it is like a rock. With the company ERP, we do every day backup, but without data breaks in twenty years)

#14

An embedded database (no matter if HSQL or Firebird) is “installed” (extracted to temp directory) when you open a table/query/form/report and it is wrapped back into the document when you close the edit session. This takes more time as the database grows which imposes a high risk of complete data loss when any component of the office suite crashes or when the machine hibernates during these seconds.
It might be possible to free a Firebird from this cage. I never tried.

#8

Stand-alone HSQL would be the solution. HSQL because it is still the best suited database for Base, however not updated. Stand-alone because any kind of embedded database imposes a high risk of total data loss.
If you still have the document with the embedded HSQL, download HSQL 2.4.1 which is the last version which is able to upgrade embedded HSQL 1.8 on the fly.
Put a copy of your database document in a dedicated directory, create a subdirectory “driver” and copy the file hsqldb/lib/hsqldb.jar from the downloaded zip archive into subdirectory “driver”.
Then download and install [Python] Macro to extract and reconnect embedded HSQLDB, run it and test your new HSQL2 database. Later you may upgrade to HSQL 2.5 or 2.6 simply by restarting the database with a replaced ./driver/hsqldb.jar

#10

This sounds like a good idea that I will explore as time allows.
I have started converting my data back to the HSQLDB embedded version and I did not see any issues like encountered in the LO 7.2.1 embedded Firebird.
Thank you so much for the good info!

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.