If you want to have a single connection be multiplexed to multiple databases, then you are going to need something like DBD::AnyData. You will have to parse the SQL statement and produce a query plan. And then using schemas for the databases, figure out which data comes from where, and craft queries to retrieve it. And then put all the data together. DBD::AnyData can use DBI sources, but I don't know if it can use them for dynamic queries.

Um... I think you misunderstand me. DBD's are used by perl code, to access external (or internal, or whatever) databases. I am trying to build the opposite. I am trying to build something that allows external database clients to connect to a perl-based data-store.

It's true that DBI::ProxyServer is such a server (in a sense), but it only speaks one end of a database protocol that is spoken by DBD::Proxy at the other end. Hence, I still wouldn't be able to get a generic database client speaking (for example) ODBC to talk into a DBI::ProxyServer.

------------
:Wq
Not an editor command: Wq
[download]

How to write an ODBC-Driver in Perl?

Good point.

From here: ODBC is a call-level interface, not an application, network layer, or database driver.

So, if you want to use ODBC (which is probably what your existing clients are able to talk to), you'll need to build a Windows DLL and/or a Unix shared library that implements the ODBC driver calling interface, and turns that into some kind of network traffic to your virtual server.

You could take a look at OpenLink's Multi-Tier product for a commercial example of this type of solution. (In fact, you might be able to decode the network protocol they're using, which would let you reuse the existing drivers they've compiled for various platforms.)

There also seem to be some free solutions that you might be able to piggyback on, like Boeireep. Googling for "odbc driver generic network protocol" should find some more candidates.

Good call. I'm actually a little emberassed, now, but yes: this is exactly why I was getting confused. Thanks.

That doesn't answer the question, however; it just helps me to phrase it properly.

------------
:Wq
Not an editor command: Wq
[download]

Let me try to explain it like this (maybe?) a little better... this is what I want to be able to do (in ASCII art):

                        ????           DBI DBD    
/---------\              [] /---------\ [] [] <===> dbX
|3rd party|     ODBC     [] |perl DB  | [] []
|software |  <========>  [] |multiplex| [] [] <===> dbY
\---------/              [] |logic    | [] []
                         [] \---------/ [] [] <===> dbZ

^^^^^^^^^^^^^^^^^^^^^^   ^^  ^^^^^^^^^^^^^^^^^^^^^^^^^
 no real control over    ^^  already exists, basically
                         ^^
                         ^^
                This is the part that
                I'm trying to get a
                handle around / maybe
                get some help with
[download]

------------
:Wq
Not an editor command: Wq
[download]

It sounds interesting. However I for one would like to get some more of that context.

The only thing it reminds me of at the moment is the pulling together of several cgi frontends (=databases) to a single frontend. I've seen some examples of that. But I suppose you want something more, eh, detached?

OK... more context, then (just for fun, though... doesn't really have anything to do with the question):

We've got a system that has a large number of identically structured databases. Because they are identically structured, then you can imagine a sort of "virtual database" consisting of the sum of all the constituent databases. For example, if you had a table FOO in each of the databases like:

(
  FOOID       number,
  FOOTYPE     varchar,
  AMOUNT      number
[download]

for example. Thus, in the virtual database, there would exist a virtual table FOO like:

(
  FOOID       number,
  FOOTYPE     varchar,
  AMOUNT      number,
[download]

  DATABASEID  number

)
[download]

So, if you took a query like:

select sum(amount), footype
from foo
group by footype
[download]

and ran it against the virtual database, what would actually happen is that the query

select sum(amount), footype
from foo
group by footype
[download]

would get run in parallel through all of the identical (actual) DBs, and they would each return their result sets to the virtual DB, which would then roll up the individual result-sets into one result set. It's conceptually as though the query were executed like:

select sum(sum_amount), footype
from (
    select sum(amount) as sum_amount, footype
    from db1.foo
    group by footype
    UNION ALL
    select sum(amount) as sum_amount, footype
    from db2.foo
    group by footype
    UNION ALL
    ...
    UNION ALL
    select sum(amount) as sum_amount, footype
    from dbN.foo
    group by footype
)
group by footype
[download]

Only with the "UNION"s being executed in parallel.

To get an even better idea, there's stuff like:

select sum(amount), footype
from foo
where databaseid in (1,2,3)
group by footype
[download]

This would get pulled apart, such that the "where databaseid in (...)" was removed from the query, and was used, instead, to control the set of databases over which to run the query.

Anyway, none of that is what I want help with. It's already a done deal... I'm trying to figure out if there are any tools, etc, on how to build an ODBC server interface... I've already got the server to back it up, I just need the ability to slap an ODBC access method onto it.

------------
:Wq
Not an editor command: Wq
[download]