Hi there,

The problem may not exist on that version (1.0.2.908-1). My issue may be
specific to 1.0.0.796-0, but I'm not sure. It is running Linux binaries using
the Linux_base that comes with FreeBSD; and with the software I need to run
"apparently" they require you use that specific version of Firebird.

If there is a FreeBSD binary (or source I could compile) version of
1.0.0.796-0 I could try that out maybe? I'm not sure if the same thing occurs
on Linux using the Linux Binaries or not, as I am yet to try it. What I can
say is the same version compiled for win32 does NOT have the issue.

-Geoff

On Fri, 25 Jul 2003 03:45 am, Bill Katelis wrote:
> 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/
> >
> >
>
> Yahoo! Groups Sponsor
>
>
>
> ADVERTISEMENT
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.