>> Otherwise you have to require each procedure written in
>> Delphi to take two additional parameters - current DB handle
>> and current TR handle, and require Delphi code to pass them
>> somehow into isc_XXX calls when callback mechanism should be
>> used (btw, will IBO or FIB+ allow such things?).
> [...]
>
> I do not understand how this is any different to C++/Java?

C++ has the same issue - as you wrote, either you use some global
variables or you pass the handles explicitly. If you use global
variables (TLS, for example) and do not want to use TLS in the engine
(or that DLL that exports the ISC API for ESPs), either application code
or DB access components must explicitly know where and how to get them.

In Java I am required to write a proxy which would translate ESP call
into Java. I can pass the handles into a generic method
"callJavaFunction" and store them in TLS. Then when Java SP makes call
to the engine, it goes through my proxy anyway, so I am able to
intercept the call and return the required handle in JNI counterpart for
isc_attach_database or isc_start_transaction. In other words, I do not
need to change the Java SP code (two additional parameters in methods)
or the driver (make it know the TLS) to handle the callbacks.

> Either you build classes to carry the additional information
> between calls (available in Delphi/Object-Pascal or C++), or
> you use global variables (aka TLS), or you use additional
> parameters. I am not aware of any secret features in C++ or
> Java that offer any other solutions.

C++ - no, but there are really-really many "tricks" in Java that you
don't have in Delphi or C++. For example it is possible to inject byte
code into the user classes when they are loaded and intercept calls to
methods on the fly (aspect-oriented programming). I can generate classes
on the fly with the method signatures I need. And so on... And these are
more or less normal techniques in modern Java - just check what in O/R
mappers is used...

> IOW it seems to me that any solution you create for C++ or Java
> _could_ be adapted for Delphi.

Any solution for C++ is ok for Delphi. This does not apply to Java and I
think to .NET (managed).

> I think the thing would be to
> ask the library developers what they need/want - particularly
> in the case of Delphi where (I assume most) development takes
> place via an existing library rather than directly to the API.

Oh yes... Unfortunately they are silent for some reason...

Roman