At 08:43 AM 16/04/2004 +0200, you wrote:

>Helen Borrie schrieb:
>
> > However, if you use Classic, then every connection has its own *instance*
> > of the server and you can use multiple CPUs. I guess the sensible
> question
> > to ask is *why* you want to access one database from two servers.
>
>This might be an direction: If embedded server behaves like classic
>there might be several applications opening the same database.
>
>But, to reach this there must be an coordinating instance - on a
>classic server there is an additional process running for access
>coordination. This would certainly break the "embedded" definition, if
>you have to run any kind of server you can use the client/server
>installation instead. For this reason an classic-based embedded server
>would not be an general solution.
>
>Transforming the coordination to be based on file-locks should be an
>enourmous amount of work which would include the need for plenty of
>tests since that mechanism is not used by the regular server installation.

Well, I give up on you Elmar. "Embedded" means "all-in-one". Either you
have multi-user - in which case you have one server, many clients; or you
have single-user - in which you have one client and one server. Now, that
might be the embedded server, it might be one single Classic process, or it
might be one client with the Superserver process all to itself.

I don't have a clue what you thought I was suggesting; but it certainly
wasn't any kind of multi-user system based on serial locking, or any sort
of file locking for that matter.

I shall let it rest.
/hb