Hi Helen,

Thank you for your help. I cannot see how things work totally as you
have described however. If it makes any difference I am actually
using FB 1.5.2.4731 on Windows XP Pro running the server as a
Windows service.

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> Not exactly. Fb 1.5 doesn't need the registry entry at all:

it "finds"

> its root relative to the location of the executable, i.e.
> YourFirebirdRoot\bin. You can safely delete the reg entry.

Sure, but if the registry entry is there then that's when problems
arise for multiple instances. I could delete the registry entry upon
installation of my application (used by a variety of users on their
machines - I'm not talking about a machine under my control, so just
by deleting the key I could create problems with other
applications), but if my app were to be installed first and then
a "normal" FB installed second then the registry entry will re-
appear and my app will then stop working.

> >It sets the location to the server exe parent folder.
>
> Nope. The reg key is set by running the instreg.exe program from

the

> commandline, from Firebird's bin directory.

That's what I meant. By "it" I meand "the normal FB install" (by
running instreg).

> >All FB 1.5 server (at least superserver) instances read that reg

key

> >and load the same firebird.conf.
>
> No, they don't. The reg key is read as a last resort if 1) the

conf files

> can't be found in the directory above the exe and 2) the root

location

> can't be found by reading the environment variable FIREBIRD.

Well I can't see that in the source code. I may be looking in the
wrong place but in ConfigRoot::ConfigRoot()
of /src/jrd/os/win32/config_root.cpp (Revision: 1.7.2.3, Sat Mar 27
13:34:24 2004 UTC, Branch: B1_5_Release) the code works like this:

1) Looks for the FIREBIRD environment variable.
2) if not found it looks for the registry key.
3) if not found it assumes the directory above the exe.

In testing FB 1.5 this is certainly how it works. The two firebird
services read the SAME firebird.conf unless I remove the registry
key or modify it in between starting the two instances.

> > They all think that they
> >are "DefaultInstance". There does not seem to be a way to tell

each

> >instance to load a different firebird.conf, other than deleting

the

> >registry key in which case they fall back to locating the
> >firebird.conf from their independent server exe parent

directories.

> >Currently the registry key that is checked is based on the hard-
> >coded #define FB_DEFAULT_INSTANCE "DefaultInstance" line in
> >registry.h.
>
> Nope.

Well as per the above code and in testing that is certainly how it
works for me. In config_root.cpp the function void
getRootFromRegistry() uses the hard-coded #define
FB_DEFAULT_INSTANCE "DefaultInstance" to read the config file
location registry key. Combined with the order above in which the
location of the configuration file is retrieved this is the problem.

> Other things may matter too...depending on configuration. You can

swot up

> on the detail in the full 1.5 release notes - that's the larger of

the two

> release notes documents in your \doc directory. See specifically

the

> section "Configuring the port service on client and server".

I have read as much documentation as I could find including the
three sets of release notes (1.5/1.5.1/1.5.2), notes on
firebird.conf, FAQ's, source code, google'd many times in web and
groups (and found a few hints on this), and searched this Yahoo
group archive.

As I think that I mentioned in my original post I have the multiple
instances working correctly with the exception of start-up where
they read the same firebird.conf if the registry key is there.

I have two FB servers installed as Windows services (my instance
registered as a service with a different service name), have
configured firebird.conf for my instance with a different TCP port,
a different RemotePipeName, and CreateInternalWindow = 0. This works
great and if I remove the registry key or modify it after starting
the normal instance and before starting my instance, and I can run
both FB instances simultaneously and connect to both by using a
different TCP port in the connection string.

Regards,
Jarrod Hollingworth