---------- Original Message -----------
From: Brian Gooch <brian.gooch.uk@...>

> Helen's 'The Firebird Book' pp 633/4; extracts from the notes follow
>
> A proc which is in use by any transaction cannot be dropped. This is s
> special issue in systems where procs are being called from
> transacations that are committed using CommitRetaining.
>
> if any other objects in the database refer to or call the proc, it is
> necessary to alter the dependent objects to remove any references and
> commit that work before the proc can be dropped.
>
> A recursive proc cannot be dropped without first removing the
> recursive calls and committing that change. Similar probs occur when
> that proc calls others, which in turn may call the proc you wish to drop.

------- End of Original Message -------

Thanks, Brian, though I think that's only tangentially related. I'm looking at
the situation where you attempt to alter the body of a procedure while others are
connected to the database -- your change is not rejected (no "object in use"
errors, etc.), but the new procedure body isn't immediately used. I think (!)
your current connection may see the updated code, but you're not sure the new
definition will be used until you drop to single/no-user. And triggers that refer
to the procedure will see the old version for a while. It's the specifics of when
the cache gets updated and the new code takes over that I'm looking for. Maybe
it's discussed in the same section.

-Philip