I've logged this issue as a request for enhancement and
I hope others will append what they think IB needs
about keeping dependencies.

Following with my example script described in:
[Bug #125219] isql -a: wrong order with domains based
on table's fields
I decided to drop the procedure named "valid16" that
handles the validation for the domain "dom16". No
problem. IB destroyed it. I still was able to select
from tab16 (the one that uses the domain and it's used
by the domain at the same time), since the proc was
loaded in memory. As soon as I disconnected and
reconnected, doing a simple
select * from tab16
caused the following (expected) message:
Invalid request BLR at offset 8
procedure id 28 is not defined
I had to drop the constraint from the domain for IB
to allow me to define the proc again (or it kept
complaining about id 28), then I recreated the check
constraint.

IB keeps track of table2table dependencies through PKs
in rdb$ref_constraints. Procedures, views and triggers
that depends on tables are tracked at rdb$dependencies
and it tracks also procedure2procedure and
trigger2procedure dependencies.

What's missing, among others dependencies:
- domain using procedure
- domain using table
=> These two cases are legal despite what docos say.
- domain using generator
- domain using view
=> Subtle consequence of above findings.
- computed field using table
- computed field using procedure
- computed field using generator
- computed field using view
=> when I deleted a proc that was serving a computed
field and tried to do a SELECT from the affected table,
I got:
Invalid request BLR at offset 26
procedure <proc_name> is not defined
Interesting: in the case of a computed field, the
binding seems to be by name and not by proc number as
in a constraint, since I only defined again the proc
and it was ready, no need to drop and recreate the
computed field.
- procedure using generator
- trigger using generator
- view using generator

C.

----------------------
User: robocop
Logged In: YES
user_id=62823

Procedures using generators and UDFs are tracked now in
rdb$dependencies.

Description

SFID: 807869#
Submitted By: pcisar
I've logged this issue as a request for enhancement and
I hope others will append what they think IB needs
about keeping dependencies.
Following with my example script described in:
[Bug #125219] isql -a: wrong order with domains based
on table's fields
I decided to drop the procedure named "valid16" that
handles the validation for the domain "dom16". No
problem. IB destroyed it. I still was able to select
from tab16 (the one that uses the domain and it's used
by the domain at the same time), since the proc was
loaded in memory. As soon as I disconnected and
reconnected, doing a simple
select * from tab16
caused the following (expected) message:
Invalid request BLR at offset 8
procedure id 28 is not defined
I had to drop the constraint from the domain for IB
to allow me to define the proc again (or it kept
complaining about id 28), then I recreated the check
constraint.
IB keeps track of table2table dependencies through PKs
in rdb$ref_constraints. Procedures, views and triggers
that depends on tables are tracked at rdb$dependencies
and it tracks also procedure2procedure and
trigger2procedure dependencies.
What's missing, among others dependencies:
- domain using procedure
- domain using table
=> These two cases are legal despite what docos say.
- domain using generator
- domain using view
=> Subtle consequence of above findings.
- computed field using table
- computed field using procedure
- computed field using generator
- computed field using view
=> when I deleted a proc that was serving a computed
field and tried to do a SELECT from the affected table,
I got:
Invalid request BLR at offset 26
procedure <proc_name> is not defined
Interesting: in the case of a computed field, the
binding seems to be by name and not by proc number as
in a constraint, since I only defined again the proc
and it was ready, no need to drop and recreate the
computed field.
- procedure using generator
- trigger using generator
- view using generator
C.
----------------------
User: robocop
Logged In: YES
user_id=62823
Procedures using generators and UDFs are tracked now in
rdb$dependencies.

Usage of generators and udfs in procedures, views and triggers is mine.
Usage of tables, procedures, generators and views in computed fields may be mine, don't remember exactly.
Usage of tables, procedures, generators and views in domains (and generally speaking, everything that a domain may depend upon) is Adriano's work.

Will close this entry now. There are two issues only:
1.- Request that Jira allows to have more than one assignee to an item. Someone take care to contact Atlassian, please.
2.- Dependency tracking for UDFs is correct although the error message always says 1 dependencies. This may be a new, low priority item.