| Subject | Re: [IBO] Firebird and Interbase on the same machine |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-05-13T13:49Z |
At 11:46 AM 13/05/2005 +0000, you wrote:
The purpose of that little unit is to override the name of the **client
library** that is dynamically loaded by the application. That happens in
advance of the first access to a database (of which there can be one or
more, on one more servers: in your case, two databases on two servers).
For two-tier client/server, the client-side API is by nature
homogeneous. You can write a two-tier IBO application that supports both,
but not both simultaneously! The problem with your proposition is that the
client for one server is incompatible with the other server, whichever
client you choose.
That's why I queried earlier whether the architecture you had in mind was
some kind of marshaling application, with no database-connecting context at
all, that would start (either or both) your (non-visual) IB module and your
(non-visual) Firebird module independently. IOW, a distributed application
of sorts. AFAIR, this was the kind of application model that
TClientDataset was originally designed for.
Take a look at Asta. I'm reasonably sure it would be able to meet your
needs and it has native support for both flavours of
IBO. http://www.astatech.com
Another modular framework worth a look would be RemObjects Hydra, also
supporting IBO. http://www.remobjects.com
There are others. These two are well-known, have support lists and have
pretty respectable histories.
Helen
> > >I had assumed that I could setup 2 data modules and two TIB_ConnectionNo.
> > >components. This should allow me to handle 2 connections to 2
> > >different database servers. If I could specify the port and client
> > >DLL, this should work (or wouldn't it?).
> >
> > On that side it should work. My query was about the client side - the
> > client library - how you would manage to load two different client
> > libraries (gds32.dll for InterBase and fbclient.dll for Firebird)
>into one
> > application...
>
>In the Firebird data module I'd include the IB_FirebirdSession unit
>you mentioned earlier and in the Interbase data module I wouldn't.
>Assuming that the server engines are not running on the local box and
>I'm using cpTCP_IP for a protocol, would a single application be able
>to access both clients?
The purpose of that little unit is to override the name of the **client
library** that is dynamically loaded by the application. That happens in
advance of the first access to a database (of which there can be one or
more, on one more servers: in your case, two databases on two servers).
For two-tier client/server, the client-side API is by nature
homogeneous. You can write a two-tier IBO application that supports both,
but not both simultaneously! The problem with your proposition is that the
client for one server is incompatible with the other server, whichever
client you choose.
That's why I queried earlier whether the architecture you had in mind was
some kind of marshaling application, with no database-connecting context at
all, that would start (either or both) your (non-visual) IB module and your
(non-visual) Firebird module independently. IOW, a distributed application
of sorts. AFAIR, this was the kind of application model that
TClientDataset was originally designed for.
Take a look at Asta. I'm reasonably sure it would be able to meet your
needs and it has native support for both flavours of
IBO. http://www.astatech.com
Another modular framework worth a look would be RemObjects Hydra, also
supporting IBO. http://www.remobjects.com
There are others. These two are well-known, have support lists and have
pretty respectable histories.
Helen