Subject Re: [firebird-support] Re: Different firebird.conf with Multiple Instances of Server
Author Helen Borrie
At 12:42 AM 30/05/2005 +0000, you wrote:
>--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
>wrote:
> > all you do is install to different directories and set difffernet
>ports for
> > each installation.
> > make sure when you install subsequent installs that you do not
>initially set
> > teh service to run until you have changed the port.
> > Alan
>
>Hi Alan,
>
>Unfortunately that doesn't work. In a normal FB 1.5 (superserver)
>install it adds a registry key to tell it where to load the
>firebird.conf file from, irrespective of where it is installed.

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.

>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.


>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.

> 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.


>I can't simply delete the reg key to force the instances to look in
>their parent directory because later the user might install FB again
>and the reg key will be there again to cause problems.

The reg key will not cause problems - whether it is there or not. What
matters is 1) to locate the conf and msg files in the correct location
relative to the server executable
AND
2) to ensure that each instance of superserver is listening on its own port
AND
3) to ensure that applications request connection to the correct port, by
including the port number in the connection string.

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".

./heLen