Helen Borrie writes:

> 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.
>

Apparently the Firebird terminology is a bit cross with my
understanding. In MySQL or PostgreSQL, a client library is a library
that you e.g. link a command-line client against to make it talk to
the server. I now see that fb_inet_server is linked against
libfbembed.so. To me this looks like this:

local: my_client->libfbembed.so->db_file
net:
my_client->libfbembed.so->fb_inet_server->libfbembed.so->db_file

And if libfbclient.so *would* work on my platforms (it doesn't), we'd
look at something like:

my_client->libfbclient.so->fb_inet_server->libfbembed.so->db_file

Is that about right?

> 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.
>

This is above my head. ldd says its linked against
libfbembed.so. period. It does not say it is linked against
libfbclient.so. At this time I don't see why my driver should use
libfbclient.so if libfbembed.so is supposed to handle it all.

> 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.
>

[...]

Ok, with that in mind I'll have to (more or less) cope with it.

> 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...
>

This is bad news. I'd like to make things work on these platforms, but
I don't want to drown this list in errors which occur only on these
platforms, and only because the ports are screwed. Is there an OS
which runs Firebird ok (except Windows which I'm not going to use)?
Would I fare better if I tried to build Firebird from the official
sources?

> 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...
>

A database abstraction layer isolates your application from the
peculiarities of database client libraries. That is, instead of
calling e.g. the Firebird API or the MySQL API functions directly, you
call the corresponding libdbi API functions. These functions call the
internal functions of whichever driver is selected, and these in turn
call the native Firebird or MySQL or whatever API functions. The
advantage of this design is that you can build and ship applications
without knowing which database engine the end user is going to
run. From the client/server schema that MySQL or PostgreSQL use
(Firebird seems to be a bit different here), an application linked
against libdbi acts just like any other client. In terms of Firebird,
an application linked against libdbi using the Firebird driver should
be able to do whatever isql can do.

> 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).

Not that I know of. I can ping localhost, and I can access web servers
using localhost.

> Another will be whether the execute rights on the directory are
> actually blocked (on these platforms) further up the filesystem
> tree.

This doesn't seem to be the case:

markus@ocean:~$ ls -ald /var/lib/firebird2/data/
drwxrwx--- 2 firebird firebird 4096 2007-12-31 00:09 /var/lib/firebird2/data/
markus@ocean:~$ ls -ald /var/lib/firebird2/
drwxrwx--- 6 firebird firebird 4096 2007-12-30 00:13 /var/lib/firebird2/
markus@ocean:~$ ls -ald /var/lib/
drwxr-xr-x 31 root 5Froot 4096 2007-12-16 01:20 /var/lib/
markus@ocean:~$ ls -ald /var/
drwxr-xr-x 13 root 5Froot 4096 2007-12-14 20:53 /var/
markus@ocean:~$ ls -ald /
drwxr-xr-x 22 root 5Froot 4096 2007-12-14 21:42 /

> Not to overlook, of course, the possibility that the directory location is on a mounted device...
>

Well, of course it is mounted, otherwise it wouldn't be there, but I
guess you mean an NFS mount or something. No, it is local.

regards,
Markus

--
Markus Hoenicka
markus.hoenicka@...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de