Am 19.04.2012 20:45, Pertti Rönnberg wrote:
From this long and very interesting thread and some other discussions
on this mailing list too, together with my own recent experiences, there
is only one main conclusion to draw:
There is no real future forLibO's Base module, perhaps not for the whole
From a non-expert user's perspective there are in fact two versions of
A >a "Light-LibO-Base" => a package consisting of LibO-Base as a
front-end GUI and an embedded db-engine HSQKDBv1.8. This package is
(could be) suitable for up to medium complex databases and be used by
'ordinary' people (like me) who does not have own skills in programming
or developing or in SQL or other languages (PHP, HTML, etc.) -- who
plainly want to create a database following instructions mechanically
B > an "Advanced-LibO-Base => the LibO-Base module to be used as a
front-end GUI connected to an external db-engine and that can be used by
people with own knowledge in programming anddb-theories and SQL and who
have a good knowledge of the whole LibO's build-up,preferable in the
I can hardly see any difference between A and B. The embedded HSQLDB
behaves exactly like an external DB. When you "open the embedded
database document" you actually _install_ an external HSQLDB and connect
the office suite to that _external_ database in cached mode (single user
on local machine) until you "close the database document" which
re-packages the external database.
IMHO, nobody needs to know anything about macro programming in order to
build useful database applications with Base. The vast majority of Base
macros are due to bad database design, save one or two clicks or they
are made to impress the boss.
There are plenty of macros for generic tasks. All the most desperately
wanted macros have been written already (clone records, refresh this and
that, open forms and reports, open text as hyperlink).
What I would describe as "Base light" is the ability to use
spreadsheets, csv files, dBase files, LDAP and popular mail client
address books as read-only data sources for office documents, mostly
This is the most important feature and the concept is superior to MS
Office if there is a computer knowledgable administrator able to work
with templates, spreadsheets, plain text and some SQL in a creative
manner. For the end user who writes a serial letter the type of data
source makes no difference at all. It is always used in the same
(slightly clumsy) way, no matter if the addresses come from Oracle
server or plain text file.
The "Light-LibO-Base" will fail because it is like a car without a gear
box: you can open it and start it but not use it as intended
Øthe installing procedure of Lib-O causes problems because of unclear
Øthe LibO-Base module as a program is half done;even basic features does
Base is not a stand-alone program and all the _basic_ features do work
well. The database backend is a mature database program, most of the
rest belongs to the Writer component.
There is just too much dysfunctional junk on top of the basic database
functionality which does not add any additional functionality.
Everything that the wizards are supposed to do can be done without the
Today's users are do not accept any _basic_ features in a highly
sophisticated office suite, no matter how well the basic features use to
work. Instead they complain about the dysfunctional rubbish.
Øthere is no documentation explicit for LibO-Base -- and will
There is excellent documentation for OOo Base which is identical to LibO
Base. Main problem with documentation is that today's computer users
overestimate their skills and do not understand the difference between
end user applications and development tools. This type of office suite
suggest that each component should be as easy to use as the text processor.
Users have to rely on OpenO documentation why there is no logical reason
to install LibO (ordinary new users does not know about any differences
between LibO and OO -- and do not know why to seek)
Øthe LibreOffice Help is a disaster -- a user new to LibO does not get
any (direct) help
LibO documentation on Base is plain wrong and misleading. Simply point
to the existing OOo docs or copy and paste that stuff.
Øthe embedded HSQLv1.8 is out-of-date and causes frustration and waste
of time because the lack of easy to get and sufficient support
There are not many users who suffer from the limited capabilities of
HSQL1.8. A high risk of total data loss is the main reason why one must
not use the embedded database. Getting an embedded database out of the
jail is easy enough.
Øthe reports is a important part of the data output; there is no Report
Builder explicit for LibO-Base or one that works properly
Calc is a very good sorrogate for a report engine even if you are not
very familiar with spreadsheets. It supports charts, pivot tables,
conditional formatting and more.
The old report engine for Writer is still there. We can open "old style
reports" that have been created without Report Builder. Unfortunately
the bundled Report Builder extension makes the old report tool
You may try to disable the extension and create a new report then. I
forgot how to disable bundled extensions. So I can't try right now.
Øthese problems all together are too difficult and time wasting for a
new user why he begins to look for easier ways to solve his need of a
database, other than LibO-Base
The average office user can not design databases anyway. MS Access users
rely on a heavy weight tool set. They are completely helpless when they
are confronted with any other database.
Unfortunately, all that misleading rubbish in LibO looks similar to MS
Access but without working as in MS Access. Same problem with some Calc
features that had been added to LibO 3.4, btw.
Øthe BoD is not interested in investing in that part of users
There is no need to invest too much. Remove all the broken and
incomplete GUI tools, keep the connectivity and form controls for the
experts. No functionality will be lost.
For the usual mail merge the current query designer is sufficient.
The plain old report wizard (but not the overambitious Report Builder)
should be re-enabled for all Writer documents.
The "Advanced-LibO-Base" will fail because:
Øthe Base module as a program is half done (as above) -- can be used
only of that minority of users who have the skill to do their own
programming to get around problems and failures
Again, I hardly use any macros at all in the context of Base. Generally
speaking, databases are too abstract for the vast majority of today's
computer users who can not deal with generic software tools. They need
tools that do exactly what they need right now (they call them "apps"
Øwho have the skill to use "real" externaldatabases (e.g. SQL)
Øthe connection LibO-Base óexternal db does not work (if not recently
I only work with external databases (HSQLDB and H2) and I know that
others use Base with MySQL. Millions of OOo/LibO users use Base with a
spreadsheet as external pseudo-database.
Many users don't know that they are using Base because the mail merge
wizard hides the fact that it establishes a database connection (to a
spreadsheet in most cases).
Øthe BoD is not interested in investing in Base
In not so very far future -- if a total destruction is excluded - our
whole world will be computerized, which means that every household must
have a computer and at least the most necessary programs for
communication (writing, mailing, internet) and calculating and perhaps
databases. Most of these private households have to or will prefer to
use freeware programs instead of commercials provided that the use is
easy, free of any problems and does not require special skills.
Everybody uses databases each and every day online. Whenever you connect
to facebook, ebay or youporn you use some database, mostly MySQL. The
cloud will do all the nasty work for you in the near future.
The fact that MS is a 95% market leader has to be accepted; MS dictates
the standards and it's products work well enough. The only real
possibility for anyone to compete MSO is a free (low cost) and perfectly
functioning product that gets a total acceptance by the children in
these grass level households.
In the last years I only saw totally incompetent MS Office users
struggling with their own endlessly nested hard formatting attributes
and working against the ribbon.
Whenever I was forced to co-edit formatted text or spreadsheets with MSO
users I was the one who kept a "master copy" and pasting the modified
content as plain text into my ODF layouts.
Within our own small business we use 100% ODF simply because I am the
one who does the templates. Output goes to the printer or PDF, weird MSO
input can be loaded into the free MS readers. I consequently reject all
OOXML sent to me personally. I am in a priviledged situation and I make
use of it.
The application that these children get used to at home and in school
will cause the real press on commercial programs also in business.
The kids would not learn anything from LibreOffice neither. All I know
about office software I learned with MS Office and books about MS Office
(the "professional" version with Access included). Non-IT persons do not
read books on software although the software has become much more
Considering a possible common aim to compete the commercials, it is a
waste of valuable resources when open source developersoverlap or
compete each others . Cooperate globally?
Who cares? In the upcoming decade of the 20ies this sort of text
processing and spreadsheets will cease to exist.
LibO can only hope that the BoD will review its strategy planning or
change the members.