Hello Terrence, > However I have also stumbled across issues 42464 "[RFE] allow to link > tables from different sources into one database file" > <http://qa.openoffice.org/issues/long_list.cgi?issuelist=42464> and > 83660 "Cannot do join query on tables from different .odb documents" > <http://qa.openoffice.org/issues/show_bug.cgi?id=83660>. These issues > have status NEW and UNCONFIRMED respectively, which I take to mean > that the requests are not necessarily good ideas.
UNCONFIRMED just means nobody looked at this issue so far to confirm it. (to me it sounds as if it is a duplicate of issue 42464). NEW means it has been confirmed, at least, but nobody started working on it, yet. > I see the following similarities among these three items: > > (*) Each requirement is to bring together into one result set data > from sources which OOo cannot currently bring together. > > (*) OOo must be able itself to join rows, as no one database engine > will necessarily have access to all the needed data. (Is it the > case now that OOo always leaves it up to the underlying database > engines to join tables?). > > This suggests to me the possibility of a new driver to integrate data > from the drivers already available. Is this idea worth thinking > about? It is. However, I would consider this the second step. In general: Yes, OOo leaves it up to the underlying engine to join tables. The "engines" shipped with Base itself - the ones for dBase and CSV files, as well as spreadsheets - is not capable of doing joins. What the "Base To-Do/Joins" requests is basically to enhance this internal engine and add join capabilities. Once this is done, and given that the engine's table access is properly separated from the concrete table implementations (which it currently is, as you can see from the fact that it can be used with at least three different table types), then the next step could in fact be writing a "backend" for this engine which joins tables from a number of different other back-ends. So, in short: Yes, both projects are related, but I'd say joins need to be done first, anayway. There are alternatives, however. For instance, Derby already has a "Virtual Table Interface" (VTI) feature, which allows creating tables from nearly any data source specification you like - including arbitrary JDBC data sources. That is, Derby is capable of joining any tables, as long they're accessible via JDBC. (There's also VTI implementations for CSV files, and probably also for dBase files.) HSQLDB, our default database engine, is not that far advanced in this respect, but already allows linking in to CSV tables, and adding support for linking in dBase tables probably wouldn't be too difficult. So, one might be tempted to use existing third-party products here instead of re-inventing the wheel ... 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]
