Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Hi :)
It is only the internal HSqlDb back-end that loses data.  If you get the
proper HSqlDb from their website then it works completely fine.  It's
designed to be extremely fast for fairly tiny databases, like almost any
address book.

So, it's only Base that loses data.  Outside of LibreOffice and OpenOffice
losing data is a heinous crime, especially in a database!!

So the main thing is to migrate existing tables into an external back-end
and pretty much any external back-end will do.  Generally any back-end is
better than the Base one.  Postgresql might be the easiest.  MySql/MariaDb
are often used.

Regards from
Tom :)

On 18 November 2014 13:59, Andrew Douglas Pitonyak <>

On 11/18/2014 07:32 AM, Alan B wrote:

On Tue, Nov 18, 2014 at 6:35 AM, Alan Pedder <>

  have been using Base to provide a database for my paintings via a
simple form.  I recorded 200 records and then added the facility to
include a photograph .jpg file and this is when the gremlins started to

It constantly issues error messages when adding data
and causes me to endlessly loose work as it has failed to write to the
table from a form for no obvious reason I can see, sometimes I can add a
  new data or several set/records on the form OK and then it will fail
with the error message as follows where the Table1 is my Table

 Hello Alan. I haven't used Base to store binaries however I have
this list for a while and used Base for a few small projects.

I expect the two primary recommendations you will get are...
1. Don't store data in Base, use a separate database back end because the
embedded HSQL is not very stable. To that end I've recently found the
native MySQL connector works well for me (never had reliable connections
with the Java or ODBC connectors).
2. Don't store binaries in Base, store a path/pointer to the binary. Keeps
the table size down, minimizes loss if the db becomes corrupted.

To re-enforce what was just said, some of which is obviously just an

LO contains a database component which stores all of the data in a single
file which is then pulled into memory when in use. This included database

If you create a "standard" Base document using what came with LO, then you
are using HSQLDB as the "back end" to manage your data. You can use other
database systems on the back-end. i am not an expert and cannot enumerate
them, but, I expect that mariadb and postgre are both examples of other
back-end database implementations that people use. The problem with that is
that (I think) that you must have these programs running as a server to
access them. The advantage is that they are more robust and less prone to
errors; especially when you store a large amount of data.

I ran into significant problems when I stored a large number of images in
a Base document backed by HSQLDB. I expect that the same problem would not
have occurred if I had used a different DB to actually store the images
(such as MySQL, MariaDB, or PostGRE). One method that may work is to not
store the large binaries in the database, but, instead, store a path to the
individual image in the DB and then store image itself on disk. I have used
this method in production systems when storing very large binaries (by
large I mean that each binary may be a couple of GB).

I stopped using Base years ago because of those Gremlins. I believe that
many of the gremlins that plagued me have been fixed, but I would be
hesitant to use it to store much binary data using HSQLDB as the back-end.

Just my opinion and perhaps others on the list can offer a more recent

Andrew Pitonyak
My Macro Document:

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.