Elmar,
I am replying here because for some reason I don't see the message you
replied to.

>> I even discover that if firebird embedded would optionally create only
>> *one* superserver instance on the first loading into memory - it will be
>> a new feature ;)

adding the TCP server code to fbembed, together with an API to start
and stop listening would be enough. Then one application in the group will
host the server & database engine for the others to use. Me and others
have been asking for this supposedly trivial feature many times in the
past, but the general objection has always been along the lines of:

E> I would not estimate this to be an issue of general interest, it dies
E> not make any sense in most cases.

It is funny how often people tend to think something doesn't make
sense just because they don't need it. ;-)
For example, most database users that don't know Firebird will react
the same way if you explain the classic shared model to them.

Anyway, there are alternatives:
a) spawning a private fbserver.exe instance, or
b) building a server layer that translates network packets to API
calls, effectively reverse-engineering Firebird's wire protocol. Much
the same as what the Java and .NET drivers do, but for the server part
as opposed to the client part.

I use a) and propriatery variations on b) quite often; I don't know of
anyone using "pure" b) so far.

E> In General this looks like embedding your application into an firebird
E> server process

No, it's really having TCP listener threads in addition to database
threads (like with current fbembed) in an application.

>> All other applications will just use fbembed.dll as a client connecting
>> to existing embedded instance.

E> Beware of the case that the first process does terminate before the
E> others.

When a server terminates, connections are closed and transactions are
rolled back. I don't see anything new or peculiar here.

>> I have in my mind such example: two applications - one which work on
>> database using GUI and one which just collect data from external device
>> and store in the same database.

E> If reducing the number of processes involved really is an issue you
E> could think about embedding the data collectiong application into an
E> server process.

I agree that building your own server with your own protocol is more
robust anyway.

Ciao
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================