Hi Helen,

> There is no "embedded IB6" so you can cross that off your problem
> list. Embedded on Windows is a Firebird-only phenomenon and did not

become

> available until v.1.5.

Yes, excuse me, I was using "embedded" in the broader sense, to mean
simply that client and server are generaly on the same machine.

I'm aware of the "embedded" version of FB and that is one option we
are looking at, but we also need to support multi-user deployments for
our larger customers.

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

Yes, embedded is very tempting for precisely this reason.

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

We have a nationwide sales and support team, so one option could be
simply to have the installer detect a conflict situation (how?), and
then alert a support operative for human intervention. We would need
to survey the customers and be pretty confident it would be a rare
situation before going down that path, though.

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

I agree, if possible. But if we are looking at a "least of 6 or 7
evils" type call, then this option is at least invisible to novices. I
would hope that desktop apps would not significantly tax either
instance of the server.

> 5) Don't overlook the issues with client libraries, especially if

you have

> to deploy fbclient.dll disguised as gds32.dll.

Indeed, this one could be a can of worms. Risk noted.

Excellent points, thank you.

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

Indeed. Luckily, we service a vertical market that we survey
regularly. I think its unreasonable to aim for 100% adaptability to
any situation, rather I will work with the business to set some
minimum, measurable "compatibility goals". We'll get hold of any known
conflicting apps and test them with ours so we can have a
compatibility list for the support staff.

I think our solution will end up being about 70% technical and about
30% policy.

I doubt this is the last time I'll need to consult the group on this one!

Thanks for your input,
Andrew