| Subject | Re: [firebird-support] Firebird Embedded ADO + ODBC Simultaneous connections |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-06-01T01:38:49Z |
At 06:17 AM 1/06/2007, you wrote:
embedded) to ensure that a database file is not able to be opened by
more than one instance of a server.
What I suppose is happening here is that your ADO and ODBC interface
layers each try to load their own instance of the combined
client-and-server DLL. Either one can do it, but not both
simultaneously. In a parallel case, for example, you can't have your
application connected to the embedded server and, at the same time,
have an instance of isql or gbak connect via an instance of it.
application might be loading multiple instances of the server - which
is actually the case if a single application tries to load two
instances of the DLL.
server model, you have one server running and n clients connect to
that server through the client dll (fbclient.dll). In the embedded
model, you have an intentional 1:1 constraint: one client instance
connected to one server. Each driver needs to address a specific
instance of the API (which is the client part of the fbembed library).
identify a running instance of the client and "piggyback" onto it...
It seems to me that embedded is not the right model for the
architecture of your application. A Classic server is compact and
would serve the requirements of your architecture.
./heLen
>Hi,Well, yes it is. But it's the nature of the Superserver (which is
>I'm working on a project that uses 2 separate connections to a
>Firebird embedded database, within the SAME executable. One portion
>of the project is using ADO to connect to Firebird, while the other is
>using ODBC. Both are independently capable of connecting, but both
>connections cannot exist at the same time. I am guessing this is
>because the file is locked by the first connection.
embedded) to ensure that a database file is not able to be opened by
more than one instance of a server.
What I suppose is happening here is that your ADO and ODBC interface
layers each try to load their own instance of the combined
client-and-server DLL. Either one can do it, but not both
simultaneously. In a parallel case, for example, you can't have your
application connected to the embedded server and, at the same time,
have an instance of isql or gbak connect via an instance of it.
>However, I'veHmm, yes, when describing this model one doesn't consider that an
>seen marketing literature that claims one of the "features" of
>Firebird is that you can connect to an embedded database multiple
>times from the same application.
application might be loading multiple instances of the server - which
is actually the case if a single application tries to load two
instances of the DLL.
>Is this limited to the same connection method (ADO, ODBC, etc)?It is limited to a single instance of the server. In the regular
server model, you have one server running and n clients connect to
that server through the client dll (fbclient.dll). In the embedded
model, you have an intentional 1:1 constraint: one client instance
connected to one server. Each driver needs to address a specific
instance of the API (which is the client part of the fbembed library).
>Do you have any suggestions how I can resolve this?I don't know of any ADO or ODBC drivers that have the capability to
identify a running instance of the client and "piggyback" onto it...
It seems to me that embedded is not the right model for the
architecture of your application. A Classic server is compact and
would serve the requirements of your architecture.
./heLen