Steffen,

At 05:41 PM 15/04/2004 +0200, you wrote:

>Hi
>
>First, there is nothing such as "embeded super server".

Erm, yes, the embedded server is the superserver engine.

>There is super server, wich allowes multiple connections and runs as
>standalone software.
>Then there is embeded server, wich is compiled into your application and
>therefor only allows that application to access the database.
>
>Independent of the version you use, you CAN NEVER access the same database
>file using multiple engines. Therefor embeded server MUST lock the file.

The embedded server locks the file because it is superserver. Superserver
locks the file to prevent multiple users logging in with different
connection paths. It is, if you like, a limitation imposed by its being
Superserver. It's a problem that I believe Dmitry intends to solve within
the newer XNET environment.

>Don't even try to change the code to allow non-exclusive access, it was done
>that way for some reason. Accessing the same database with two engines will
>destory it. Definitly.

Yes definitely: it's never going to be a solution to the impossible goal
of having two servers accessing one database. Peter - just stop thinking
about it. It destroys databases faster even than ripping out the hard disk
and throwing it out of a tall building.

>One engine can never know what was changed by the other engine in RAM
>already.

Not just RAM, but disk as well.

>Use Super Server, NOT embeded for this.

The goal of "two servers, one database" is not possible - like you don't
get carrot juice from squeezing oranges.

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.

/heLen