Nando Dessena wrote:

> 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:

Nice.Could it be however even simpler.For example just a mutex check
inside fbembed.dll on first DLL loading and one function to set this
mode and mutex name ? Second ,third and other fbembed.dll load call will
function (in this mode) just like a local client code only.
Only the first fbembed.dll load will create superserver embedded engine.

This is just an idea - I'm not going to force it or even not much care
if somebody doesn't likes it.

> 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

I remember hot discussion about embedded Firebird requirement long time
ago (I was one of persons who liked embedded Firebird idea a lot).

I'm glad we have embedded now,just sometimes I think that it's too
limited for some cases.Not much too complain however ;-)

Regards
Boguslaw Brandys