Helen Borrie writes:

> >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 why is it then that fb_inet_server is linked against libfbembed.so?
Just trying to make sense of all this.

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

I think I'm almost there. I'm just trying to find the missing piece in
the puzzle: which library do I have to link against in order to get a
client that is able to pass a request to fb_inet_server? I was under
the impression that libfbembed.so should do the trick (in addition to
being able to handle local requests without the server). Is
libfbclient.so that client library? Is libfbclient.so the same as
libfbembed.so sans local access?

> >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 reason why I'm so much insisting on libfbembed.so is that local access
happens to work on my platforms. Access through the server doesn't
work at all (Debian) or only partly (FreeBSD). libfbembed.so gives me
at least a chance to test the actual driver functionality (running
queries, retrieving results and so on).

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

Let me repeat one question: can you recommend a freely-available OS
which runs Firebird out of the box? I'm using Debian solely as a Linux
testbed to avoid "BSDisms" in the code which I develop on FreeBSD. I'd
be happy to replace it with SuSE or Fedora or whatever if this helps
avoiding the Debian-specific Firebird problems.

BTW the FreeBSD people do supply binary packages of FreeBSD, see e.g.
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/databases

but these wouldn't even run due to some undefined symbols...

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

I'm afraid now you're making it too complicated. libdbi has been in
use since 2001 and is doing fine except for some hassles with
Firebird... Think of libdbi merely mapping generic API calls to the
database client API calls of whichever engine the end user runs. It is
client-side only.

regards,
Markus

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