At 11:45 AM 31/12/2007, you wrote:

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

No.

my_client->libfbclient.so->host:fb_inet_server->db_file

So your remote connection (whether it be from a POSIX client or a Windows one, must take the form:

hostname:/hard/path/to/db_file

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

What is? Maybe we have a bit of a terminology problem here, so let's clear that up. Firebird is a client/server engine consisting of two modules: the server engine and the remote client. Remote client = a shared library that surfaces all of the remote API functions. No more, no less.

Then, we have a specialised model known as "embedded". On POSIX platforms, it is roll-together of the (internalized) functions of the remote API and a form of the server module's code that doesn't "connect to a database" at all in the client/server sense. It connects to the database *file* in the application space of the OS user that owns the libfbembed.so process. It channels data around within that application space and by no other means.

Isql is a client *application*. As with any client application, isql uses a client library to pass function calls across the API. As with any client application, if you start it with a "local" path it will try to find libfbembed.so and, if successful, it will operate using the internal server code within the application space.

Also, as with any client application, if you connect using a network connection string such as hostname:/hard/path/to/db_file, on Classic that request goes to [x]inetd and [x]inetd will invoke an instance of fb_inet_server for it. Under these conditions, isql runs in the user's application space, while the fb_inet_server process instance runs in firebird/firebird application space.

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

I don't either. I haven't seen anything mentioned by you so far that suggests you need to libfbembed.so at all, except possibly for some ad hoc admin tasks that ordinary users wouldn't do...but you're just not telling us enough about what you're aiming to do here.

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

Maybe...although from what I can tell, the FreeBSD people (who *never* supply binaries) are pretty thorough about QA-ing their stuff. For Debian/Ubuntu, we have to hope it gets better and, specifically, that their porting guy can be persuaded not to tamper with 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.

OK, so, you have one of two scenarios:

1. n-tier, with (at least) 2 abstraction layers on the server side: one to interpret the DBI calls and one to perform the actual database access.

2. 2-tier with Fat Client, where all the interpretation stuff happens remotely at the client and (ultimately) pushes native requests through the firebird client.

For (1), if your localized data abstraction layer makes a single proxy connection to service multiple clients of your interpretation layer, the embedded model might suit. Your remote client application won't even be interested in a Firebird client: it will connect to the interpretation layer.

For (2), like with any fat client setup (ODBC, ADODB, et al.), you'll need the whole wagon and horses on the client side. If the client applications are on POSIX, then libfbclient.so will be deployed as part of the client clobber. If the client applications might be on Windows, then you would deploy fbclient.dll instead.

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

Yes, I do mean an NFS mount or something (SMB, blah blah).

./heLen