Hi Chad,

What you suggest may arguably be a good idea, but you need to
understand that the model you are proposing is not how embedded works.

Embedded is a version of Superserver rather than Classic for a start,
which means it has a single host application controlling the DB file
(normally FBServer), rather than a process per connection.

Embedded isn't really designed to do what you seem to want it to do.
It is basically superserver encapsulated within a single DLL. Because
of that, if a second instance of the dll is loaded in another program,
that is the same as a second instance of a superserver.

So why use embedded? There are a number of places where it is really
useful. For example, you may have a simple stand alone application
where you need a DB backend but you do not want to have to install
Firebird or interfere with other Firebird or Interbase installations
on the same machine, it works perfectly. Another example would be an
n-tier application where a certain amount of data needs to be cached
at each tier, but again you don't want to be stuffing around
installing a database. (not that installing FB is a particularily
labourious task, but it is always easier to dump a few dlls in the
applications folder. Yet another example is if you want to release
your program as a self contained USB Key that you plug in then double
click a shortcut, no installation, just plug and go. We have a version
of our product that can do this so that sales people can take it with
them and give them the experience on their own machine.

But if running the FB installer is the thing that bugs you, find the
script and duplicate what it does inside your own installer. It is
just a bunch of files, a registry branch, and an environment variable.

Adam