> Not quite true. Vulcan runs just fine with the default
> configuration files, as does Firebird. Neither runs without a
> configuration file.

fbembed.dll runs without configuration file without any problem, at
least FB 1.5 embedded. I have not test FB 2.0 embedded for now, but I
hope this is not broken.

I do not know how Vulcan checks for the config file, but in FB 1.5
embedded there was an issue that effectively prevented a configuration
file when used with Java if $FIREBIRD variable was not set - Firebird
was checking the directory where binary was located, in that case a
plase with java.exe. Nobody was willing to put any configuration in
%JAVA_HOME%\bin directory.

But you are right - Vulcan has problems when its configuration is
missing. From my point of view that is a pity, or even more, that is
mistake.

> Roman, those handles are available. Accept it and get on with life.
> The engine just doesn't have a clue as to what the Y-valve might
> have invented for an external handle.

Jim, I do not talk about handles that Y-valve have invented. I do not
care what the handle is - engine makes it available for me. Whatever
it decides to be suitable is fine for me. I will return that handle back.

For now that are external handles invented by Y-valve, since the calls
go back into Y-valve. If you decide to export me jrd8_XXX entry points
plus the Attachment and Transaction pointers (which can be easily
defined as void*) - is also fine with me. As long as API remains
something like

typedef prototype_isc_transaction_info(
ISC_STATUS *,
void* tr_handle,
short,
char *,
short,
char *);

I do not care how tr_handle looks like and whether that is some 32-bit
(or 64-bit) number invented by Y-valve or that is a pointer to the
Transaction instance.

I also understand your reluctance to export the internal API
(especially if that will be jrd8_XXX calls wrapped by
InternalConnection), since you have the problem to remodel the
internal API in this case.

But from the other point I have a problem with IscDsc API. For me that is

a) functional overkill - there are many more entry points than our
lovely ISC API,

b) inability to use existing components to do internal database access.

You force all languages to use the same API, or remap it to the
ISC-like API each time a new language is added. People that use Delphi
are used to FIB+ or IBX. Why do they need to learn new API to access
the database from withing the external procedure?

Having a quick look through the InternalConnection classes it seems
that all they sit on top of the ISC-like API (those jrd8_XXX calls,
which are similar to the isc_XXX calls). So now I try to understand
what that cannot be exported as an API for external procedure. I'm not
done with it, but if you can save my time, I will be very grateful.

Roman