At 04:29 AM 31/12/2007, Markus Hoenicka wrote:

>Hi,
>
>first of all, thank you for your lengthy explanations. The picture has
>cleared up a bit, although I'm still struggling.

I probably can't answer all of your questions as Debian is a law unto itself and the Debian builds are not maintained by the project. Similarly with FreeBSD, although at least they have the means to build your own... for years I've been asking Debian/Ubuntu and FreeBSD people to feed back on those OS-peculiar quirks so we can maintain some platform-specific pages for them. What actually happens is that, eventually, they solve their problems and we never hear back.

>This seems to be a key point of the whole story. Our firebird driver
>has so far been linked against libfbclient.so, but isql uses
>libfbembed.so (or so ldd says). This is why I keep seeing different
>behaviours between the command line tool and our test app. Linking the
>database driver of our test app against libfbembed.so changes the
>picture entirely. Local connections now work without a hitch

Isql uses whatever client is a) indicated by the connection path and b) available. If you are writing a driver that is hard-coded to connect to libfbclient.so then you will have to softlink libfbembed.so, if you want to make embedded connections. The decision (or error) about which kind of connection is being requested is made on the basis of the parameters in the DPB, regardless of what platform the client is connecting from. If there is no server element in the connection path, a POSIX version of the server can't connect you *unless* the client library is libfbembed.so. And, when a connection is made from libfbembed.so, you are not running an instance of fb_inet_server, but an instance of the server engine that is embedded in libfbembed.so.

>, with a remaining (unrelated) problem on FreeBSD which I'll post separately.

I saw that posting - it's very unlikely you'll get an answer to it in this list. I suggest that you (invite you to) post a fresh message on that topic to the firebird-devel list, making it perfectly clear what version of Firebird you are talking about, in finest detail. We have no way to guess what these outlier platform builders are doing or which versions they are doing it to.

>However, this again leaves me wondering. The documentation is not very
>explicite about the difference between these libraries (BTW none of
>the PDF documents contains the strings "fbclient" or "fbembed"!). I've
>found one reference
>(http://www.firebirdsql.org/manual/qsg2-disk-locations.html) which
>tells me libfbembed is a "local client with embedded engine, Classic
>only". isql is linked against this library.

It will be linked against libfbembed.so *if* your installation is Classic *and* you use a local path. But do be CLEAR that "local path" means a path to a location that is under the control of the same host machine. You cannot connect to a database by *any* means if the location is a mount of a filesystem on another host machine.

If you give isql a network path, it makes a connection through [x]inetd. If you use the local loopback server it can use the client code in libfbembed.so; if you use the node address, you must use libfbclient.so.

> However, e.g. OpGuide.pdf uses isql to access remote databases as well, and it doesn't mention anywhere that this is going to work only with one of the server types. So which document is right?

The QSG is right for Firebird; the OpGuide is (more or less) right for InterBase; and, overall, the basics in the OpGuide are equally (more or less) right for Firebird as well.

However, what was lacking in the Borland area was cross-platform integration. There were idiosyncratic versions for various UNIX platforms, they had an aged Classic distribution for Linux whose upgrade to v.6 had hardly begun when IB 6 was dumped.

On POSIX platforms, IB had only Classic. Their various platform distros shipped with a client library called libgds.so. But libgds.so had two versions, depending on which CD you bought. One version was the embedded server client, which Firebird renamed to libfbembed.so at Fb 1.5; the other was the network client, which we renamed to libfbclient.so at Fb 1.5. Borland never had a Superserver for any POSIX platform. We have had one all along. So the "FirebirdCS" packages go out with both clients, while the "FirebirdSS" packages have just libfbclient.so.

Things have tended (and still tend) to get sticky around the Debian and FreeBSD ports because they do their own thing. In the case of Debian, you can't even rely on a "version" containing the same stuff as the project releases...

>And if libfbembed can do both local and network accesses, why and where would I use libfbclient then?

Basically, use libfbembed.so *only* for an embedded application and that application must be totally, physically LOCAL. Typical usage would be a web server or equivalent n-tier layer; or for a stand-alone system you are deploying for strictly single-user access. Otherwise, stick with the remote client. *Any Firebird client library on any platform* can connect to a database on your Firebird server.

>Is there one library which can access both classic-server and
>super-server?

The remote client. Firebird is client/server consisting of a server module and a remote client module. Any remote client on any platform can connect to any database on any platform (same or different). "Embedded" is a specialised variant for a specialised purpose - that being the need to run a client application locally, as the only client.

>As a database-abstraction project, do we have to maintain separate drivers for local and network access? Or for
>classic-server and super-server? Or will one driver, written in a
>sufficiently ingenious fashion, meet all needs?

It's probably a lot simpler than you're making it, but it's not clear to me what you mean by "as a database-abstraction project". Firebird's native environment is 2-tier client/server, interoperable across the supported OS platforms. The embedded model can be considered a beneficial option for deploying an n-tier system or an appliance...

[...snip...]

>That is, by all I've learned so far isql should have no problem
>connecting to fb_inet_server, which as user "firebird" is allowed to
>enter and to alter the directory where it is supposed to create a
>database. However:
>
>SQL> create database 'localhost:/var/lib/firebird2/data/libdbitest';
>Statement failed, SQLCODE = -902
>
>operating system directive open failed
>-Permission denied
>SQL> create database 'ocean:/var/lib/firebird2/data/libdbitest';
>Statement failed, SQLCODE = -902
>
>operating system directive open failed
>-Permission denied

Explore further what the access rules are on these platforms. One to look at is whether you need to configure localhost specifically in the hosts and/or hosts.allow file (or their equivalents on these platforms). Another will be whether the execute rights on the directory are actually blocked (on these platforms) further up the filesystem tree. Not to overlook, of course, the possibility that the directory location is on a mounted device...

>That is, neither using localhost nor the real node name gets me any
>further. Interestingly, the same appears to work on FreeBSD. I've got
>these permissions:
>
>markus@yeti:~# ls -ald /var/db/firebird
>drwxrwxr-x 3 firebird firebird 512 Dec 30 18:20 /var/db/firebird
>
>and the server permissions are set up like this:
>
>markus@yeti:~# grep firebird < /etc/inetd.conf
># enable firebird database engine
>gds_db stream tcp nowait firebird /usr/local/bin/fb_inet_server fb_inet_server
>
>The only obvious difference is that I use Firebird 2.0.3 on FreeBSD,
>whereas my Debian box runs 1.5.3. However, I'd expect both versions to
>work. Or am I again missing something (not so) obvious?

When talking about the standard Firebird builds, the differences are not about differences between Fb 1.5 and Fb 2. The Debian port of 1.5.3 was a notorious mess and maybe you need to chase up a fixed version. You might get some insight from various articles that have been archived in the Technical Articles section at www.firebirdnews.org.

> > Yup. Well - it's not VERY obvious if you don't understand the differences between the three server models. So decide which model you want to work with and you should be able to proceed without further frustration.
> >
>
>As mentioned previously, your explanations have made this matter
>somewhat more transparent to me (thanks for that!). However, as we're
>looking at a database abstraction layer, it is not up to me to decide
>which server model to use. Our driver(s) must support whatever the
>end-users choose to run.

Then you're not going to get far if you model your software on embedded. I can't advise at all as I have no idea what you're trying to build. I doubt that either Debian or FreeBSD is an ideal basis for anything generic, though.

>This partially answers my questions about which client library to
>use. libfbclient.so appears to be out then?

I don't know. Are you building a 2-tier client/server system, an n-tier system where there is one and only one database client (that may or may not be physically local) or an appliance? or what? "Client" means different things in each of these environments...

./heLen