At 10:59 AM 25/07/2003 +1000, you wrote:

>Helen,
>
>Is this a CS specific feature ?

I think you might be right...

>because I can successfully connect to a
>local physical db via 2 separate isql sessions on FirebirdSS-1.0.0.796
>on the same host as follows:
>
>root# isql /opt/interbase/examples/employee.gdb -u sysdba -p sysdba

A-ha, removed Classic and installed SS 1.5 and --- and so can
I. Interesting...

Now to reinstall Classic and check through that procedure again. If I
confirm what I encountered before, it can perhaps be explained by deducing
that it is the *process* that acquires the filesystem lock. Since xinetd
gives each connection a fb_inet_server separate process, the first process
that connects directly to the database file (i.e. not via the network
layer) gets the lock and excludes other processes that attempt to connect
by the same route. Those that connect subsequently via the network layer
don't get excluded because the database file is already open. (??)

With SS, there is only one process, and that is already running when the
first user tries to connect - so it's never the user that gets the
filesystem lock, but the ibserver process itself. Subsequent connections
to SS just thread off from the already-running process, so exclusive file
access isn't an issue.

It will be good to get this right...

heLen