Hi Andreas, > Completely off-topic, just for the records and my personal relieve:
I changed the subject accordingly ;-) One item beforehand: I disagree with that "all-in-one"-files are as useless as you seem to see them. There's a group of users which expects exactly this from a database application: a single file with everything in it. That's not the same group which uses PostgreSQL and MySQL, and it has only intersections with the group which expects to be able to link to / process .dbf files obtained from elsewhere. However, like it or not, this group exists, and the decision for Base was to target (not necessarily exclusively) this user group. That decision, to a certain extent, is the justification for the current all-in-one format, and some priorities set for development. Also, this focus is not really something I am going to debate here at the moment, sorry to say this. I don't consider questioning the very basis of Base's concept a productive discussion. To some of the points you raised: > 1. Embedded databases have been reported to lose data which is inacceptable. > 2. Performance of embedded databases is too bad. > ... > 7. Finally, embedded binary data has nothing to do with ODF. That's true. And at the same time, those points describe the problem: A database file format has nothing to do with ODF, IMO. We can either have ODF, in particular the current package format, then we can't have performance and reliability. Or we can have performance and reliability, by using a file format which allows instant random access to all its bits (which is not remotely the case with ZIPs), then the space for ODB shrinks to storing certain parts of the overall database document in ODF-compatible XML streams, but within a sub stream of a proprietary container format. The longer we have the current format, the more I am convinced that for all-in-one database files, ODF - the *package* part of it, not the XML part - is the wrong choice, exactly because your first two points. However, changing this needs a long breath, since the debate whether ODF-conformance is to be rated higher than efficient and reliable database documents is ... well ... let's say there are stakeholders in this discussion with different opinions. > 3. You can not create desktop-links to reports nor forms. You have to > open the container and browse to the form or report you want to work with. I miss the number of the RFE for this here. We so far considered this feature not that important. If you (or you and a lot of voters) can convince us of the opposite, it might be implemented. Effectively, this is one point in a long list which some people declare to be essential. There's a lot of different opinions about a lot of items on this list ... > 4. Far too many users do not understand the whole concept of embedded > vs. linked data in a container format. They simply create a "document in > Base format", connect to an existing set of tables (dBase, text, > spreadsheet) and expect to get a fully functional database. Or they > create a "native" one and end up in the middle of nowhere, even if they > have some experience with Access. Hard to argue here, because "expect to get a fully functional database" (with the implication that this is not the case), and "end up in the middle of nowhere" are not really clear problem descriptions. > 5. There is no native documentation for the "native" type of databse. I > don't accept http://hsqldb.org/web/hsqlDocsFrame.html as native > documentation of OOo's native database format. That's true. Ideally, Base would offer the UI to use the backend features, so people could use them without reading documentation (except the online help, perhaps). Well, this indeed is not the case. > 6. The query designer and various wizzards are the only GUI-tools. > Currently there is no way to create Base-extensions. The query designer > covers a tiny subset of possible selects in hsqldb, whereas all the > other types of databases are nearly unsupported (select, distinct, > where, order by, count(*), that's it). Yes, the query designer is outdated. Seriously outdated. I cannot but agree here, perhaps we indeed should put the item "new query designer" higher on the list. > A single-file database has no advantage over connections if the overall > concept and it's restrictions is that complex and difficult to understand. > The old concept in versions 1.x allowed forms and reports of any type. > Arbitrary documents could be linked to the datasource in the datasource > pane. I prefer simple Calc reports (pivot tables and pretty formatted > query imports). I miss the ID of the issue which requests to embed Calc files into database documents. Or the ID of the issue which requests to offer a feature to link arbitrary documents into a database document ... As said above, I don't plan to argue on the database document concept as such, so adding those features - and perhaps more - which allow a workflow more like it was in 1.x times is the only way to go. > Instead of fixing all that odb-mess it would be far more important to > implement joins on dBase tables Seems we have different priorities here. > and a common set of stored procedures > for any kind of table. Not sure what you mean with this. > If a redesign where possible at all, I would like to discuss another > concept (yes, I believe in the term "impossible" for practival reasons). > ... What you describe pretty much is one of the alternatives we considered for 2.0: use data sources as before, put them into a nicer/easier GUI, make it easy to export/import/bundle them. The decision was made in favour of the all-in-one-file database, and somehow I continue to think it was the right decision. You can't fulfill all wishes at once. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
