Dimitry Sibiryakov wrote:

> On 30 Sep 2006 at 8:17, Jim Starkey wrote:
>
>
>> Writing a new provider to support integrated cross database access has
>> many advantages. One is that it isn't dependent on particular engine
>> versions. It would work on all versions, Interbase, Firebird V1,
>> Firebird V2, and Vulcan. It wouldn't break the engine during its
>> development. It would support cross database access across process
>> and server boundaries. It would support cross database access across
>> major version and even across a mixture of Firebird and Interbase
>> databases. It would have a release cycle independent of the current
>> Firebird engine. It also could reuse major encapsulated classes from
>> Vulcan -- the SQL parser, memory managers, sort, the mover, etc.
>>
>
> And if this mega-provider is ever implemented, what will be a
> reason of using other providers directly? Why not pass all queries
> through it?
>
>

That a possibility. There is a small but measurable delta cost in a
simple indirection. But using it will incur one or more of the following:

1. A more complex connection string encoding the paths, account, and
password information for the target databases
2. A static "mega database" definition containing the above
3. A mega-database specific statement containing the path, account,
and password information for a target database.

There is no free lunch. The mega-database provider still needs
connection information for the targets. And, for the single target
database case, there is an unavoidable analysis and pass forward case.
Finally, there is a requirement that a user understand what it does and
how to use it. This is probably the biggest barrier.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376