At 11:20 AM 10/02/2009, you wrote:

>> >Does IBO make use of the Firebird.conf settings
>>
>> Of course not. IBO is an interface for client applications. Client
>apps can't read files on the server. If there's a non-default port
>configured in firebird.conf, the server will listen that port and the
>client will have to make sure it attaches through that port.
>
>Who said anything about reading a file from the server? Chapter 9
>talks about using a client side copy of Firebird.conf, which is what
>I've been shipping with my client app. I thought by changing the
>ports in that client-side copy of Firebird.conf, fbclient.dll would
>use those ports, but alas not, IBO continued to use 3050 unless I
>tweaked the connection string.

If the client library can detect a local copy of firebird.conf (and at this distance, I'm not at all certain it can) it would at least require more configuration/mapping on the client machine than merely having the file "somewhere". I certainly wouldn't recommend relying on it, unless (by a question in firebird-devel) you could establish categorically that the regular client will consult firebird.conf.

>If I decided to use a different RemoteAuxPort, does fbclient.dll
>obtain that setting from the server when connecting on the service
>port, or does the client need to know beforehand. If so, do I use a
>client-side copy of Firebird.conf, or do I have to instruct IBO on the
>new RemoteAuxPort number?

The client doesn't know or care about the RemoteAuxPort. The events port is normally acquired by the server at random. Client interfaces use an AST callback mechanism (implemented in IBO, for example) to "register" an interest in whatever the server spits out to this port (whatever it is). RemoteAuxPort can be configured for the case where the server's firewall doesn't expose random ports for use by the server for broadcasting events. So the client has no more need to know the server's event port when it is pinned by RemoteAuxPort than when it is just randomly acquired.

>I've always thought it possible to use a client-side copy of
>Firebird.conf, I just want to get it straight in my head, whether it
>has any effect, or it's all done by IBO.

IBO doesn't do anything that the API itself can't do. The isc_attach_database() function expects a fully-composed connection string (preceded by a short integer describing the length of that string). Once the isc_attach_database() request is passed, the string itself is parsed at the "Y-valve" (the "black box" logical interface between the client library and the server, that does not expose itself to the API) to determine how the connection is to be made.

IBO collects up the properties Server, Path and Protocol and constructs this string on behalf of the application. So, in IBO terms, the non-default port is part of the string that you provide in the Server property.

I can't see anything in the API that enables a client interface, e.g., IBO, to poke anything into that parameter, per se, although I don't see too much of an obstacle in publishing a property for it and parsing it in during the construction of the string, before it counts characters. You could do that yourself right now, by subclassing the TIB_Connection.

The client library itself *might* have the capability to read a local firebird.conf (provided it can find it) from within the Y-valve and massage the connection string accordingly - I just don't know. As that seems important for you, I recommend asking the question in firebird-devel. I'll watch the thread and update the v.1.5.5 release notes if clarification seems necessary.

Helen