Sorry I have not commented on this sooner.
You are definitely on the right track.
IBO is very close to doing what you want, it just has troubles with the SQL
trace monitor because it has to use global hooks instead of its own local
hooks.

Jason Wharton
www.ibobjects.com

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of Geoff Worboys
> Sent: Tuesday, July 05, 2005 6:53 PM
> To: IBObjects
> Subject: [IBO] Enhancement Suggestion: Client Libraries
>
>
> Hi All - but in particular Jason,
>
> I am fiddling around with a project, I wont bother you with
> the details but the upshot is that I would really like to be
> able to specify the Firebird client library at startup
> according to a command line parameter (or perhaps a registry
> entry).
>
> That is to say; I want to be able to choose library "x" in
> some situations and library "y" in others - without having to
> recompile the application.
>
> The problem with the current code is that the IB_Session proc
> "ReserveSessionHookRef" is called from various initialization
> sections (IB_Session and IB_Monitor - and indirectly from
> any IB_Component that is created during initialisation).
>
> Initialization sections are called before we get into the
> the program itself, which prevents runtime customisation (or
> at least prevents it from being easy and predictable).
>
>
> I am guessing that some of the work in ReserveSessionHookRef
> MUST be called during initialisation - the critical section
> stuff. However that procedure also calls "AcquireOriginalHooks"
> which is where the library gets opened and the library function
> hooks get acquired.
>
> I did the following test with IB_SQL: I renamed the FB library
> so it could not be found and started IB_SQL. It started with
> no complaints - so obviously the function hooks were not
> essential at that point (more about this aspect in a moment).
> I then left IB_SQL running and renamed the client library back
> again and tried to establish a connection. It worked! The
> TIB_Connection actually checks whether the hooks are acquired,
> and calls AcquireOriginalHooks if it needs to do so.
>
> So... for "normal" situations there appears to be no need to
> acquire the library hooks until we are ready to actually make
> a connection. We could remove the early (initialization)
> opening of the library, which would then allow a program to
> start up and specify what library file it wanted (in a global
> variable or by defining a global function), and normal access
> would be able to proceed without other changes.
>
> With appropriate changes it could even be possible to unload
> the FB client library at runtime and (optionally) specify a
> different library for the next task.
>
>
> I have identified some situations that can cause problems...
>
> Starting IB_Monitor before establishing a connection
>
> Calling GetISC4Path or CreateDatabase (these call the API
> hooks without checking if they have been initialised)
>
> There also appear to be issues in IB_Connection from alternate
> threads - I suspect the hook pointers just need initialising
> to nil in IB_Session.
>
> Can anyone think of other potential problems of not initialising
> the library hooks until a connection is made?
>
> Given the limited number of "problem" situations we should be
> able to explicitly deal with those in some appropriate way.
>
>
> Any other thoughts on this topic?
>
> Jason, perhaps you have other plans for tackling this issue.
> I seem to remember we discussed it some time ago, but I do not
> remember what we decided.
>
> --
> Geoff Worboys
> Telesis Computing
>
>