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

Hi everbody,

although I am not an data IT person, I've been a long time user of 
openoffice/libreoffice. I'll allways wanted to use LO as an official front end 
for an database; first of all because I do not know how to program html (even 
with all those facilities we have today) and also I don't want to start now 
learning how to program in an script language. So I always hoped to find an 
GUI front end for an database, that would feel very similar to FileMaker 
(Mac/win). Well those that claim, that base is already very similar probably 
never used FileMaker intensly. Even Kexi which is also claimed to be as good 
as FileMaker is mile away from it. Don't take me wrong here I don't want to 
make any apology to this program, but they really got it quite right.

Even though still thing that LO and similar are the way to go. But I think for 
sometime its being a unstable GUI crashing once and a while. After lefting it 
to rest for some time, last week, I took courage to restart an small project I 
wanted to move from an Calc tables to an real DB. I started using Kexi and 
tested again if LO Base would connect to the MariaDB with the native mysql 
driver it went flawlessly. One improvement I immediately saw (or at least as 
far as I remember), was the hability to see tables not generated by LO and 
read/write data as well. The last time I used base, if I remember well, base 
could only read tables from an DB if it generated the tables.

But other simple things like changing the order of fields (with MariaDB as 
backend) do not work in LO but in Kexi it works. It seems also that crashing 
event were eliminated or reduced to a minimum. I don't want to compare GUI and 
list advantages or disadvantages, I just want to point out that although big 
leaps happened since I last tried to use base, what makes me very happy. On 
the downside, to become an great and easy to use GUI for developing grahical 
DB interfaces, if comparing with FileMaker, there is still along way to go. I 
tell this because I've used FileMaker for a while. I've learned to use it in 
quite a short time (~ 3-4 month) and did fairly complex reports, queries, etc 
in graphic mode.  I can not say the samething for SQL likes. Probably my 

But I belive that base is the right way to go, because it is an multiplataform 
program that links to several diferent DB programs and is open, I think two 
key conditions for the success of an software, as Fernand Vanrie mentioned. 
More up to date literature and how-to's would be a nice help and also an 
harder development unfortunately this last one I can not help due to my 



On Monday 02 March 2015 20:23:49 Tom Davies wrote:
Hi :)
Apparently another great database program to use as a back-end is
Postgresql.  Some of the Postgresql people worked with the LibreOffice
people to make a really good connector and then got that connector into
LibreOffice main trunk.

So, Postgresql has an advantage over MySql in not needing a connector,
apparently.  I dunno how it gets updated though!

Also MariaDb is a drop-in replacement for MySql and i think a few places
use it but continue to claim they are using MySql.  Apparently all the
MySql connectors work just the same but i've only heard from a very small
number of people about that and the person who makes/builds the MySql
connector wasn't certain they would work.

I think those are all the larger database back-ends but HSqlDb is
supposedly faster and more efficient with small databases such as almost
all address books.  There are tons to choose from though so you might find
that whatever is being used somewhere already can probably be viewed and
edited through Base.  I think the way Base makes it so easy to connect to
external back-ends is one of the huge advantages that Base offers.  Instead
we try to cripple it by giving it an internal back-end to make it as broken
as Access.
Regards from
Tom :)

On 2 March 2015 at 19:04, Andreas Säger <> wrote:
Am 02.03.2015 um 19:33 schrieb Florian Reisinger:
Just a short note: Base can connect to a MySql database using a


I even think, knowing not much about Base, that an external database for

storage is a very good way to go...Am 02.03.2015 16:54 schrieb Peter

External is the one and only way to go. The embedded HSQL 1.8 simply
does not work well enough. There are far too many reports of total data
losses which is inacceptable for a database product.
You can connect MySQL via ODBC, JDBC and the SDBC driver built into the
office suite.
I prefer external HSQL 2.3 via JDBC because the office frontend is
tailored around HSQL, because HSQL 2 converts formerly embedded HSQL 1.8
on the fly and because any connection to an external HSQLDB requires
only one file hsqldb.jar anywhere on the system. In server mode it takes
this file plus self made start/stop scripts and a backup script.
I just opened my oldest HSQL 2 database running in server mode on a
Windows machine, accessed during 12 hours a day by means of Writer forms
and Calc reports from 7 client machines. The first record is of
2011-Apr-28. This database never caused lost a single byte of data. Of
course we run nightly backups anyway.

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.