--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> This is a **relational** database. That means it has DEPENDENCIES.

The

> SQL language - specifically, here, the DDL subset - has a lot of

stuff

> going on at the binary language level to protect dependencies -

that's how

> a RDBMS works.
>
> A UDF declaration is a database object. When you (validly) declare

a UDF

> to a database, it becomes a database object, with a dependency

between the

> UDF object in the database and the library and entry point in the

local

> system. As soon as a SP or constraint uses a UDF, a dependency is

created

> between this UDF object and the SP or constraint. So, by the chain

of

> dependencies, you make the SP or constraint dependent on the

presence of

> the external dynamically-linked object supplying the valid entry
> point. That's why FB has to stick its nose into UDFs when you refer

to the

> object.

Helen, to be honest, I too don't understand why engine checks
validity of _source_ BLR when altering and dropping procedures. No
questions about _destination_ BLR. Dependencies are stored in system
table specially assigned for this, IMHO engine can just clear
dependencies of source and create for destination. Perhaps this is
just my ignorance on internals. Thanks to FB developers, we at least
can now drop procedure which contain invalid calls of another ones,
but why can't directly alter to valid instance? BTW, if there is
dropped index mentioned in explicitly planned query within SP, we
still can' drop it and are forced to hack copying BLR of empty
procedure into invalid one to drop it. Seems illogical to me.

Best regards,
Alexander

PS - Seems I'm starting to get into the habit of unusal for me role of
disturber instead of conservator :))