Am 19.04.2012 20:45, Pertti Rönnberg wrote:
LibO-folks,
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
LibO suite.
From a non-expert user's perspective there are in fact two versions of
LibO-Base
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
linux environment
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 mail merge.
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
instructions
Øthe LibO-Base module as a program is half done;even basic features does
not work
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 wizard.
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
obviouslynot be;
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 inaccessible.
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" nowadays).
Øwho have the skill to use "real" externaldatabases (e.g. SQL)
Øthe connection LibO-Base óexternal db does not work (if not recently
fixed)
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 sophisticated.
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.
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
