Am 14.04.2012 13:04, drew jensen wrote:
Hi Andreas,
Sorry, I can't agree with your advice to avamk on this one.
Sure you can edit tables on 'your' database, as long as he is the one
doing the work the fact that it is a server based system is meaningless
in this regard
As for Base features, the problem is that there just aren't enough of
them, or they are half done, not too many.
//drew
All those half done features should be removed. They don't really do what they promise to do and all they promise to do can be done without them. They do not really serve any purpose other than looking similar to MS Access but leaving new users alone in frustration.
When they come to the forums we have to explain how to do it from scratch or how to proceed where the tools left them alone.
- A table designer which supports only constant default values but not dynamic ones. It does not support the CHECK clause neither. It is a matter of seconds to type the respective ALTER TABLE commands to enable the missing features and CREATE TABLE is very easy to learn so you may even leave the table designer and the relations designer.
- The table wizard lets you compose all kind of things which is counter productive if you don't know exactly what you want while it's a waste of time if you know what you want. In particular, it does not really care about matching data types between potentially related fields. It may lead to major frustrations and next time you start with the designer since you need it anyway.
- A query designer which produces no more than most simple baby-SQL. Most of the time I click together some field names because the tool is at hand but then I finish the statement in plain text. While in design view, I avoid saving complex but working queries because they may be rendered useless by the graphical query designer.
- I can type SQL faster than I am able to do the right thing with the query wizard.
- A form wizard which supports only one pair of form/subform and for this pair only two aspects of a 1-n relation. It never creates any list box which is the key control make relations editable. The tiny little fraction of possibilities covered by the form wizard is not worth using it. Almost every time I need more than that and so I use to start on a blank Writer sheet (sometimes it's a Calc sheet).
- I don't know much about the report designer. Has there ever been a version where all features worked as advertised? For me it was very useful when I had to impress a gang of banksters, but usually I build informative ad-hoc reports on spreadsheets when formatted print data are required. With the right collection of styles in a template this is a matter of max. 5 minutes including pivot tables and charts.
- The old report wizard was the one and only feature in the whole office suite which enabled us to bind row sets to Writer tables. It is still there when you disable the report designer, but in OOo v1 we could do that trick with every stand-alone Writer document.
A hobbyist database designer like me needs one lazy Sunday afternoon for a dozend of interrelated tables and a set of input forms to edit each of the relations. The result would be the first version of something that is usable by anybody who is able to order something on ebay. It is more functional, reliable and comprehensible than what millions of people try to achieve in Excel. The development work stops at a certain point while the input forms keep on collecting data input for years to come and maintenance free. At least this is my experience with 3 Base/H2/HyperSQL-projects and I am confident that I would be able use the same database with any other frontend tool or convert the backend database to a similar backend.
Leaving aside any of the above mentioned development "helpers", just typing (or copying) plain SQL in a Notepad-like text editor and drawing forms manually, the development process would take no more than 2 extra hours (if any). My Emacs editor has an SQL mode and I added generic text snippets for auto-IDs, foreign keys and two-column ID+Name lists. It takes care of quoting and braces. Working with plain text SQL in a capable developers editor is more convenient than any of the Base tools.
In the end we are talking about development tools. We develop something which is hopfully convenient and intuitive to use while the development process can not be convenient nor intuitive because we need to fully understand all the technical abstractions in order to hide them away from the user.
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
