Hier noch ein Statement, das vielleicht etwas sauberer ist *, als das in der ersten Proc. Es basiert tatsächlich auf den Dictionary Infos zu Foreign Key Constraints und liefert mehr Infos, als benötigt.
Stammt von hier und ist etwas modifiziert:
http://www.alberton.info/firebird_sql_meta_info.html
Dort gibt es auch eine Variante, die auf rdb$depencies basiert, aber die geht bei mir gar nicht.
Ich finde es ja seltsam, dass diese Daten offenbar nur über die Indexinfos erreichbar sind. Das hat m.E. logisch nichts miteinander zu tun. Aber da die Indexerzeugung bei ForeignKey Erzeugunng ebenfalls automatisch läuft (und dabei auch bestehende Indices ignoriert, also zusätzlich/doppelt anlegt), muss man das wohl als pragmatischen Ansatz sehen.
Code:
SELECT rc.RDB$RELATION_NAME as Constraint_Tablename,
rc.RDB$CONSTRAINT_NAME,
s.RDB$FIELD_NAME AS field_name,
rc.RDB$CONSTRAINT_TYPE AS constraint_type,
refc.RDB$UPDATE_RULE AS on_update,
refc.RDB$DELETE_RULE AS on_delete,
refc.RDB$MATCH_OPTION AS match_type,
i2.RDB$RELATION_NAME AS references_table,
s2.RDB$FIELD_NAME AS references_field,
(s.RDB$FIELD_POSITION + 1) AS field_position
FROM RDB$INDEX_SEGMENTS s
LEFT JOIN RDB$RELATION_CONSTRAINTS rc
ON rc.RDB$INDEX_NAME = s.RDB$INDEX_NAME
LEFT JOIN RDB$REF_CONSTRAINTS refc
ON rc.RDB$CONSTRAINT_NAME = refc.RDB$CONSTRAINT_NAME
LEFT JOIN RDB$RELATION_CONSTRAINTS rc2
ON rc2.RDB$CONSTRAINT_NAME = refc.RDB$CONST_NAME_UQ
LEFT JOIN RDB$INDICES i2
ON i2.RDB$INDEX_NAME = rc2.RDB$INDEX_NAME
LEFT JOIN RDB$INDEX_SEGMENTS s2
ON i2.RDB$INDEX_NAME = s2.RDB$INDEX_NAME AND s.RDB$FIELD_POSITION = s2.RDB$FIELD_POSITION
WHERE -- rc.RDB$RELATION_NAME='TESTTABLE' -- table name
-- AND rc.RDB$CONSTRAINT_NAME='FK_B' -- constraint name
-- AND rc.RDB$CONSTRAINT_TYPE IS NOT NULL
rc.RDB$CONSTRAINT_TYPE = 'FOREIGN KEY'
ORDER BY s.RDB$FIELD_POSITION
*
Einen Schönheitspreis gibt's bei dem Thema offenbar nicht zu gewinnen.