Warning

If you change a domain's definition, existing PSQL code using that domain may become invalid. If this happens, the system table field RDB$VALID_BLR will be set to 0 for any procedure or trigger whose code is no longer valid. If you have changed a domain, the following query will find the code modules that depend on it and report the state of RDB$VALID_BLR:

select * from (
  select 'Procedure', rdb$procedure_name, rdb$valid_blr from rdb$procedures
    union
  select 'Trigger', rdb$trigger_name, rdb$valid_blr from rdb$triggers
) (type, name, valid)
where exists
  (select * from rdb$dependencies
   where rdb$dependent_name = name and rdb$depended_on_name = 'MYDOMAIN')

/* Replace MYDOMAIN with the actual domain name. Use all-caps if the domain
   was created case-insensitively. Otherwise, use the exact capitalisation. */

Unfortunately, not all PSQL invalidations will be reflected in the RDB$VALID_BLR field. It is therefore advisable to look at all the procedures and triggers reported by the above query, even those having a 1 in the “VALID” column.

Please notice that for PSQL modules inherited from earlier Firebird versions (including a number of system triggers, even if the database was created under Firebird 2.1 or higher), RDB$VALID_BLR is NULL. This does not indicate that their BLR is invalid.

The isql commands SHOW PROCEDURES and SHOW TRIGGERS flag modules whose RDB$VALID_BLR field is zero with an asterisk. SHOW PROCEDURE PROCNAME and SHOW TRIGGER TRIGNAME, which display individual PSQL modules, do not signal invalid BLR.