--- David Johnson <johnson_d@c...> wrote:

> The complaint is that the tool stopped the database team from slitting
> their own throats, and the rest of the company's throats with theirs.

I say! Hasn't anybody (not even Helen :-) ever thought of the
possibility that changing the database structure might not be owed to
poor design but to, let's say, extensions and new features that are
demanded by customers? Don't you *ever* buy an upgrade to any
application you have? Why should a database be the only object that
has to be perfect from the start? What if your developing environment
had prevented you from making changes in Firebird 1.0, stating that
altering a function would violate its dependencies? There would have
never been a Firebird 1.5! And if anybody had complained about that,
people would have told him that it was his own fault that Firebird 1.0
was so poorly developed that it needed to be changed!!

No - anything you work out with and for a PC must have the ability to
be continually developed! And I have a hard time myself with FB in
that matter. Compare it, for instance, to postgresql: You can change a
stored procedure in any way you like, and it has never ever corrupted
my database (not to mention slit my throat) that I was able to do so
(you can even use domains as data types for input parameters, a BIG
"everything would break down if we did this" no-no in FB).
On the contrary, it has enabled me to update my application in a
simple and effective way. With Firebird, I meanwhile prefer writing
new functions and just ignoring the old ones, since it is virtually
impossible to change anything in an existing function (and I mean
ANYTHING... we are not talking about changing the return data type or
such things, just any internal calculation within the SP).

Sorry for attacking a holy cow if I did so, but I seem to be not the
only one whom these things bug.

Stefan