On Tue, 2007-12-18 at 10:44 -0500, Jahn, Ray (R.) wrote: > Dear Jeffrey: > > There has been a discussion (see below) by several participants on the > same subject. Based on the past discussion, the need for this feature > appeared to arise primarily in a medium to large business > environment. I do not know whether a RFE has been created for this > feature. It might take more time for the OO Base community to > accumulate enough momentum and resolve toward such type of competitive > features in business operation. > > Your contribution to help explain the "business" value and potential > competitive market pull resulting from this feature is very welcome. > > Sincerely, > > Ray Jahn
I've played with this idea a bit for my own 'Axis' project ( http://entropy.homelinux.org/axis ) ... note that my website is currently down ... crappy DSL modem ... They way I've been doing it is a little messy, but it works well for my current needs ( read-only ). My project is in Perl. Steps I'm using: - Parsing the query and identify all tables involved. - Use $dbh->column_info to inspect the fields in each table. - Create 'temporary' tables in a local SQLite database for each table - Query from each table / dbh and dump into SQLite, making use of pieces from existing where clause to start with - Query other DBs, with a MASSIVE where clause consisting of foreign keys from prior steps, and other bits from the original where clause - Final query of SQLite tables to pull everything together Currently, I'm only talking to MySQL and SQLServer. And as noted already, I'm only doing read-only stuff. If you want to do updatable queries across multiple database servers, then I don't really think this is a worthwhile goal. It's too messy to implement, and it only serves to enable people to create bad applications anyway ... ie you shouldn't have multi-table updates, even on the SAME server, and especially not on separate servers. Yes MS Access does allow this. But every single time I come across an updatable multi-table query, it's the source of at least one problem. If you want to support read-only queries across multiple DBs, then this is a lot easier to implement, and actually useful. In the medium term people with multiple DB servers should be looking at standardising on 1 server platform. Anyway, if anyone is interested in working on a read-only solution that utilises SQLite for local caching / aggregating, I've got bits and pieces in place for it already ... in Perl. I suppose to be of maximum use this would have to be ported to a new project, written in C, which is beyond my abilities at this point. Lastly, when I was enquiring on this topic myself some time ago, someone pointed me to the Muldis::DB project ( which is also written in Perl ). -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
