Hi,

Below is the snippet of the post I mailed in Firebird-java,

>I have got a DB connection to the Firebird server (super sever) ,
>to the database say 'c:\temp\one.fdb'. Now I like to switch the
>database to 'c:\temp\two.fdb' in the same connection ..

> I tried like as in the below code snippet ,


> Connection conn = fb.getConnection("c:\temp\one.fdb");
> //do some operation
> //commit
> //then swith db
> conn.setCatalog("c:/temp/two.fdb");
> // I am not sure of catalog setting will work


> but db switching like above failed

Since in firebird DB switching is not supported in same connection.
I need to create a one more connection with db "two.db". It will
occupy additional resource in the sense of port , object , etc.

Our concern is not about the performance but optimizing the usage of
resources.

If you agree with this kindly consider this as feature requirement,
or if you have any other view share it with me ,


with regards,

Peter Kenzie
--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@a...> wrote:
Hi,

> The reason for using the same connection for "switching" the DBs is
> to avoid too many Connections to the server. DBs like MySQL, Oracle
> have provisions to switch the DBs like this (and also carry-over
> transactions) at runtime. For example the MySQL has the catalog
> support and the Oracle has a "Alter session.." support. This way, we
> will be able to avoid many I/O connections and at the same time work
> with multiple DBs in the same database server. To sum it up, its
> purely for optimization purposes. It'll be good if Firebird too
> offers such a support, otherwise, we need to go for connection/DB
> approach only.In our application we will have many database in
> single db sever. Depending upon request we will switch database,

Please post this as a fature request in the Firebird-Support or
Firebird-Architect list.

From my personal experience time needed to establish connection can be
neglected compared to the time needed to compile and execute
statements.
AS3AP test suite shows only slight peformance improvement when using
connection pooling compared to the improvement when statement caching
is
used. In case of Firebird you can rely on opening new connection to a
database when needed, but transactions will remain database-local
unless you
use XADataSource and a distributed transaction coordinator.

Roman
--- End forwarded message ---