[libreoffice-users] Re: OO Base has serious critical issues...

A warm welcome to all frustrated Base users,

IMHO, LibreOffice should cut off embedded HSQLDB, together with the idea 
of a "database document" and all the useless wizards.
- After 6 years the embedded database is badly known as data eraser.
- The table wizard does not help to build a database. It may save a few 
clicks when building dysfunctional nonsense.
- After 6 years of development the table designer still lacks dynamic 
defaults and constraints that are available on the "command line" 
(menu:Tools>SQL).
- The query wizard and its parser supports baby SQL only. As soon as 
field functions come into play it becomes counter productive. Sometimes 
it turns valid SQL into invalid or dysfunctional SQL.
- The form wizard can not map relations to forms and controls. It never 
creates any list box, which is the key element to access foreign keys.
- Each new version, even bug fix release, raises new issues and 
regressions. I had to skip 3.2 and 3.2.1 and update from 3.1.1 to 3.3 
because 3.2 and 3.2.1 had issues which rendered some of my input forms 
useless.
- Whenever some minor Java problem occurs, it most likely affects the 
Base wizards and HSQLDB. Nevertheless, we can turn off Java and see that 
we still have everything at hand to connect with non-Java databases, 
build forms and pull data into documents.

What LibreOffice could do to make the whole thing work for really 
advanced users and professionals while improving the current 
functionality for most other users:
1. Go back to the database connectivity of version 1 where database 
configuration was written into the office configuration. Basically this 
means getting rid of database documents which cause so much anger and 
confusion among office users who can not understand why they should 
"convert" their spreadsheets to databases before they can do a mail 
merge. Users really hate this "conversion" which actually is a about 
linking. The mail merge wizard can hide that annoying "database 
document" but the file manager won't. As soon as there is a problem or 
demand for tweaking the data source you are confronted with that obscure 
"database document" that does not keep any data (well, it's a 
configuration file isn't it?).

2. Make connectivity actually *work*. There are far too many problems 
related to standard interfaces ODBC and JDBC. Some built-in SDBC drivers 
are of bad quality. Using csv in all components could be so much easier 
if the text driver would be a little bit more advanced. LDAP crashes 
LibO. Forms work with one type of connection but not with another one. 
Sometimes an easily accessible configuation file would be more helpful 
than a GUI dialog which never reflects all the driver options. I 
consider the new driver extensions as a step towards better connectivity.

3. Drop some of the wizards for the above mentioned reasons. Database 
design is development work since the result is aimed to a supposed end 
user. It makes no sense to create fool proof design tools when - for the 
benefit of the end user - the designer must not be a fool. The current 
wizards for forms and tables do not help anyone. It may save me a few 
clicks when I know how to reorganize the result I had already in mind 
before starting the wizard. Many others are lost with bad table design 
and dysfunctional queries when they finally are trying to to fix the 
spoiled basement by means of incredibly complex forms and Basic code.

4. Instead of database documents, OOo should offer distributable 
front-end packages. The current document with embedded HSQLDB behaves 
like an extension anyway. It installs a HSQLDB into a temporary 
directory every time you open the document and it repackages the 
extension when you close the document. It happens far too often that the 
whole HSQLDB gets lost when anything goes wrong while (un-)zipping the 
database.
A distributable front-end package would merge its configuration with the 
user profile, drop forms and reports to the local file system and 
register the whole thing in the office (just like OOo 1.x did). The 
separate database back-end remains in place offering 100% of its 
functionality, performance, safety and security (if connectivity is not 
an issue anymore). Forms and reports can be loaded from each other by 
means of simple hyperlinks. At some point most of today's Base 
developers spend hours to get rid of the Base window one way or the other.

Since version 1.1 I use databases together with spreadsheets and form 
letters. Since 2004 our private cash journal is still the same old dBase 
file dynamically linked to data pilots and charts. I am capable to use 
Base as a fronted to some existing database back-end given that the 
back-end follows certain design rules. I'm not picky when working things 
are not as fine polished as in other front-ends.
I also managed to worked with a fairly complex embedded HSQLDB. It took 
2 weekends of development time and we used it for 18 months with tiny 
changes in form design but 20,000 records in 12 interrelated tables.
For me and my wife the Base component turned out to be the most useful 
office component as soon as I had learned how to work around bugs, 
limitations and bypassing most of the "features" as well. I avoid the 
wizards. I avoid the SQL parser and most macros. I use plain SQL 
wherever I can in order to get correctly working queries. I use the tool 
bars to draw fairly usable rather than "perfect" forms. I use Calc or 
the plain old report wizard for clear reports rather than beautiful 
ones. I use the report designer extension every now and then when I need 
to show off a little.
From external databases with stand-alone form documents and direct SQL 
I get best results and more freedom with less scripting. The Base 
related parts of the API are even more seriously broken than anything 
else. I won't expand on that.

This is how I see the role of database connectivity in office suites: 
OpenOffice.org used to be focussed on the ODF document standard. 
Databases can "fill out" parts of documents while input forms are most 
useful when they can be bound to some storage rather than being on 
round-trip as documents.
The databases by themselves have nothing to with documents. Therefore 
Base seems to be technically overstretched because it tries to look like 
another document format without being able to hide away the fact that it 
is just a (sloppy) container format for documents, data storage and 
configuration.
All the Base tools for back-end creation are known to be insufficient. 
There are plenty of mature and free database tools tailored to the 
different types of databases. LibreOffice is not obliged to do this part 
as well. Just like any code editor is better than our Basic editor, most 
of the generic SQL editors and composers outperform the infamous query 
designer.

Too much development time has been wasted for foolish gimmicks and a 
counter productive container format on top of the extremely useful 
database connectivity.
Apart from confusion and high risk of total data loss the "database 
document" has nothing to offer to the average user while many "power 
users" try to leave behind the "database document" when they leave 
behind the first drafts of a project. The support forums and lists are 
full of solutions which effectively work around Base.

Thank you for reading,
Andreas Säger


--
Unsubscribe instructions: E-mail to users+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/users/
*** All posts to this list are publicly archived for eternity ***