Subject | Re: [firebird-support] Re: Different firebird.conf with Multiple Instances of Server |
---|---|
Author | Helen Borrie |
Post date | 2005-06-03T04:56:50Z |
At 02:42 AM 3/06/2005 +0000, you wrote:
list. Embedded on Windows is a Firebird-only phenomenon and did not become
available until v.1.5.
Furthermore, if other vendors' embedded Firebird apps are already installed
on the system, it is no problem. Each embedded install is totally
self-contained.
Just don't get confused between "embedded" and an installation that is a
server and a client application installed on the same machine. They are
not the same animal.
1) You don't need to consider "Firebird 1.5 Embedded" in this issue at
all. These installations don't conflict with existing installations,
either full server OR other v.1.5 embedded installations.
2) You DO need to consider conflicting installations of Firebird 1.0.x and
IB6. They can be done but not by any "hands-off" procedure. I don't think
this is in your equation though.
3) The conflict between an existing IB6 server installation and a Firebird
1.5 server has the small but significant issue of using separate ports. Fb
1.5 has the means for using an alternative port, IB6 doesn't.
4) An existing Fb 1.5 server *should be used*. It does not make sense to
impose on the customer the need to run two doses of the same server side by
side.
5) Don't overlook the issues with client libraries, especially if you have
to deploy fbclient.dll disguised as gds32.dll.
understanding what's needed for YOUR particular packaging. There is no
"one-size-fits-all magic cloak" for hands-off deployment of a database
server. It's a dive into a rocky pool, no matter how you look at it.
./hb
> > I have two FB servers installed as Windows services (my instanceThere is no "embedded IB6" so you can cross that off your problem
> > 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
>
>Thanks for the tips Jarrod (and Helen). I'm presently planning out an
>upgrade to an embedded install of IB6 to FB1.5. Its complicated by the
>fact that some clients use apps by other vendors that rely on embedded IB.
list. Embedded on Windows is a Firebird-only phenomenon and did not become
available until v.1.5.
Furthermore, if other vendors' embedded Firebird apps are already installed
on the system, it is no problem. Each embedded install is totally
self-contained.
Just don't get confused between "embedded" and an installation that is a
server and a client application installed on the same machine. They are
not the same animal.
>I'm wondering if installing the service and client with a customPoints:
>service name and port number would avoid collisions with both IB6 AND
>other apps' installs of FB??
1) You don't need to consider "Firebird 1.5 Embedded" in this issue at
all. These installations don't conflict with existing installations,
either full server OR other v.1.5 embedded installations.
2) You DO need to consider conflicting installations of Firebird 1.0.x and
IB6. They can be done but not by any "hands-off" procedure. I don't think
this is in your equation though.
3) The conflict between an existing IB6 server installation and a Firebird
1.5 server has the small but significant issue of using separate ports. Fb
1.5 has the means for using an alternative port, IB6 doesn't.
4) An existing Fb 1.5 server *should be used*. It does not make sense to
impose on the customer the need to run two doses of the same server side by
side.
5) Don't overlook the issues with client libraries, especially if you have
to deploy fbclient.dll disguised as gds32.dll.
>Does anyone have any experience of managing this type of deployment?Asking the questions you have been asking is the recommended way to *begin*
understanding what's needed for YOUR particular packaging. There is no
"one-size-fits-all magic cloak" for hands-off deployment of a database
server. It's a dive into a rocky pool, no matter how you look at it.
./hb