At 05:54 PM 15/04/2004 -0500, you wrote:

>Is there any projection for when this dependency will be removed? I do
>realize you can set the global by hand, but it makes a lot of since to me
>that this should be selected via a property of the TIB_Connection component.

I think the time has come when it would be good to consider implementing a
property in TIB_Session for this. But IBO has always had a way to make
different builds invoking different clients, that's (to me) more elegant
than messing around with the core pieces such as ib_constants.

Look at the unit ib_session511.pas in your IBO root directory. That was
originally put there as a model for using the IB 5.1.1 client with IB 5.6,
because events were broken in the 5.6 client. Just rename and modify this
unit so it points the IB_Constants.IB_GDS32 constant to the library you
want to use. In your project code, you just have to remember to add this
unit as the first in the project's uses clause. Keep this pair (dpr +
ib_session add-in) separate for each custom build.

Some people actually *need* the Firebird-built gds32.dll, since their
customers might be connecting to any one of Interbase, Firebird 1 or
Firebird 1.5 and they don't want to ship different builds for different
servers. You can still do this; although it's really only a matter of
time before IB and Firebird diverge too much to retain the current
interoperability.

Another strategy is to add a Registry key for the client library location
and make your ib_session_whatever unit read this key at the appropriate time.

>I have just been trying to remove all traces of IB from my box and was
>surprised to find that I could not edit a query (via the wizard) without
>having GDS32.DLL installed.

A project in the IDE is a client the moment you connect to a database. :-)

>I changed the declaration to look for
>fbclient.dll instead (yes, in IB_Constants.pas). Everything works
>super-duper well.

Yes, that works too, and it's fine if the app only ever has to find a
Firebird 1.5 or higher client. Lots developers use a range of different
tools with Firebird 1.5, that they want to use with Firebird 1 or
Interbase as well. So the gds32.dll option has to be around, because it
forms the "middle ground".

But, I do agree with the idea of TIB_Session providing a way to set the
library name and location as a run-time option. Envisage, for example,
IB_SQL with a radio box on the Connection tab, with this property sitting
behind it.

Helen