Helen,

I still can't reproduce the original problem.

I have just removed the SS version and installed FirebirdCS-1.0.2.908-1
and can successfully, as root, connect to the same db with 2 different
isql sessions
and in this case without even supplying a username/password.

very interesting ...
bill

Helen Borrie wrote:

>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
>
>
>
>
>To unsubscribe from this group, send an email to:
>firebird-support-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>