To the original poster of this thread, apologies for straying far from your
question.

Nigel - - -

At 11:32 AM 5/08/2004 +1000, you wrote:

>...
>
> > >If you mix direct file access, and TCP/IP via
> > servername/path/to/db, you
> > >will wreck databases!
> > >
> > >(Unless things have changed in the last two years...)
> >
> > It's not so, and never was.
>
>We had significant problems if two simultaneous connections were made as
>follows:
>
>isql -u sysdba -p masterkey /path/to/database.gdb
>isql -u sysdba -p masterkey server:/path/to/database.gdb
>
>This was on classic server, under FreeBSD, and the directory was owned by
>the Firebird user.
>It almost seemed that the lock manager was bypassed when using the direct
>filesystem connect(or something nasty). If changes were made on one
>connection, the other got terribly confused.
>Haven't tried it since 0.9, as we just decided to keep to the
>servername:/path/to/database.gdb.
>
>I can guarantee we wrecked databases, but as Helen said, it's fixed now...

OK, Nigel, let's avoid perpetuating a myth. This is a case of confusing two
*different*, platform-specific bugs and your comments aren't applicable to
the Windows versions at all, nor to certified Linux versions. What I
described was the solution to the Windows path string bug. I could not
begin to say whether *your* particular problem is solved in recent FreeBSD
builds, or not.

Generically, in the POSIX implementations, there are two *distinct*
clients: one, for Classic only, creates its own instance of the server and
literally does connect directly to database files. It's the one that's
used the older ESQL application model for developing server-based apps,
which can update database pages directly from client code. Originally, this
was the only Firebird model available for FreeBSD.

The other client arrived in the InterBase 6 beta era, for remote
applications connecting to Superserver. In Firebird 1, that client, which
was also named libgds.so, didn't support this direct local connect at all.
I do now recall that there were corruption problems with some of these
experimental non-Linux builds, and maybe some of the trial Linux builds
too, if you tried to use the wrong client. I heard of a case back then,
where a Classic database on Linux had apparently been corrupted by having a
mix of client libraries connecting on the same local server....however,
it's not clear, from archive history anyway, whether a working SS version
of Firebird 1 for FreeBSD was ever released.

In Fb 1.5 Classic, the old direct-connect client was renamed to
libfbembed.so and the remote-capable client was renamed to libfbclient.dll.
libfbclient.dll is the full-fledged remote client and it can also be used
to connect to Fb 1.5 Classic. Fb 1.5 SS doesn't support direct connect and
you can't use a local connection string to connect to it, either (local
connection only via tcp/ip local loopback).

Those early Firebird 1 FreeBSD builds weren't ever certified. It wouldn't
be surprising if there were still bad mixtures around. It's evident that
several people were posting Firebird stuff into the FreeBSD tree, beyond
the control of the Firebird project. If FreeBSD users are still having
problems, they'd need to organise some testcases to reproduce them and try
to get the attention of whomever is primarily responsible for the FreeBSD
builds---I think possibly still Chris Knight? ...although the current
uncertified 1.5 builds for FreeBSD 4.8 and 4.9 were built by someone
else... You could inquire on firebird-devel if you're interested in moving
towards a stabler version of Firebird on FreeBSD.

/heLen