> >> In Vulcan, we may have a few engine providers within a single
> >> installation.
> >>
> >
> > I have always wondered about the real need for such an
> > installation/setup.
> >
> Simple. You have a development system and would like to install a

beta

> without disabling the previous release. On a database by database

basis

> you backup and restore the database. Nothing in the client changes.
> Slick?

Sure, if that is a real problem which matters to the developers.

But the larger/real problem is in deploying the software that developers
create which is the true problem.

> This was the way things worked before Borland trashed the

architecture.

> It works extremely well and users love it to pieces.

I would suggest that Borland decided that IB/FB needs more attention to
deployment issues and not simply a tool for developers.

> In this case, the dispatches doesn't (and doesn't need to) know squat
> about the providers. Just ask 'em, in the prescribed order, "can you
> attach this". Then the magic starts.
> > The current Vulcan approach, IMHO, is only suitable for selected
> > installs where there is someone (sysdba) responsible for the

management

> > of the configuration.
> >
> No, all it requires is that Firebird developers understand the
> architecture before they decide to trash it.

It also requires the solution creator to truly understand the larger
problem -- it is not about development, it is about deployment!


I have 10 developers, who are each able to handle changing IP port or
server names, not exactly rocket science. But, I have 40 deployments
which need to support!


Sean