At 08:23 AM 7/08/2003 +0200, you wrote:

>Dimitry et al,
>
> >>Does a version of the embedded server exist for linux?
>
>D> It exists from the very beginning time. But it was and is a part of
>D> classic server. Not this modern dedicated version of SS.
>
>BTW, is fbembed.dll technically a classic server, a superserver or
>none of the above?

It's a superserver but without the capability to accept multiple clients,
or networked clients of any sort (not even localhost). Connection is
direct between the client and its embedded *server* and client and server
share the same inter-process communication space. It can only run on one
single physical machine. and the application has exclusive access to the
database as long as it is running. It doesn't go via the security database
to establish its right to connect.

But, in all other practical respects, this is like the normal superserver
architecture - application code accessing the server using exactly the same
function calls to the API as a regular client/server application
makes. You could, for example, take your current Delphi 3 application
code, replace the client library identifier with fbembed.dll (or even just
rename it to gds32.dll), recompile it and you're done.

While Dimitry isn't wrong (the Classic server always could be accessed by
"embedded applications") we have a fundamental confusion here in the use of
the term "embedded" to refer to two different architectural models.

The old "Embed, deploy, relax" thing refers to host code applications
written so that all of the SQL is embedded in the code (C, Cobol or
whatever) in special blocks of "ESQL". Some of this SQL is quite
idiosyncratic to embedded application use. The C source code is run
through a pre-compiler (gpre) which generates intermediate code to replace
the SQL blocks. This intermediate code is native host language source code
which packages all the SQL into parameters for macro calls to the server
engine. After the precompiling, you compile the resulting sources and you
have a compact chunk of object application code containing precompiled SQL.

This model doesn't use anything like fbclient.dll or an "embedded
client-and-server" like the one D. Yemanov made for Windows. It doesn't
even use the regular client library (fbclient.dll or/and gds32.dll). The
"API calls" are, if you like, embedded in the application code during the
precompile - except, they are not API calls but equivalent communications
with the engine that are passed via macros. This kind of application is
"just another client" which attaches remotely to the same server as the
other clients in the network. It *could* attach as a local client, e.g. if
it were a layer in a multi-tier system, but it's more likely to be a remote
client.

heLen