--- In firebird-support@yahoogroups.com, "avner_liat" <avner@...> wrote:

>
> Hi,
> I'm new to this database and trying to decide what will be the best
> usage of the database in my case.
> I have an exisiting client server architecture and I want to use the
> firebird in the server side only.
> I support in my server multiple clients which can update the database
> concurrently by sending application specific commands.

Where does it send the commands? If it is some data abstraction layer
or service then this is fine. If it is to Firebird, then embedded is
not for you.

> This is why I want to open concurrent multiple database "transactions"
> and do for each client its work in a dedicated transaction.
> Since the only process which access the database is the server I was
> thinking of using the embedded option.

Be careful you do not mix the terms connection and transaction. A
connection is to a database, a transaction is a set of commands that
should be considered atomic. A single connection can have multiple
transactions, and a transaction can span different databases too.

Embedded is not for every purpose, but there are some cases where it
is an excellent fit.

> My questions are:
> 1. Is using the embedded server option will give better performance
> (because no networking and round loops are involved)?

Probably, depends on the system but yes most of this overhead is removed.

> 2. Will hosting the database in my process will require less resources
> than running the SuperServer?

Only in the sense that the above loops are not needed, but embedded is
literally superserver inside a dll, so all the caching etc will be the
same.

> Are there any other issues I should consider?

You will not be able to connect to the database from a single process
running on the database server at a time. This means that your admin
tools (FlameRobin etc) will not be able to connect to the database
while your service is running. It also means that gbak can't run while
your service is running (however I am led to believe you could use the
services API from within your application). Also be aware that user
security is effectively bypassed. You are able to make multiple
simultaneous connections from different threads of the single process
running the dll.

Adam