Hello,

I have question. This may be an easy one to answer but I haven't
been able to figure it out yet. Where is the information on
constraints stored, sufficient to create the same constraint again?
EG. RDB$RELATION_CONSTRAINTS has the relevant fields RELATION_NAME,
CONSTRAINT_TYPE, and CONSTRAINT_NAME. So if I wanted to construct
the DROP statement as a string, i would say:

'alter table ' || RELATION_NAME || ' drop constraint ' ||
CONSTRAINT_NAME

But if I needed to construct the ADD statement as a string, i would
say:

'alter table ' || RELATION_NAME || ' add constraint ' ||
CONSTRAINT_NAME || ' ' || CONSTRAINT_TYPE || '(' || <<??????>> || ')'

But where would I locate the <<??????>>?

Or am I going about this the wrong way entirely?

Context information: I am writing an application in which it is
sometimes necessary to disable triggers and and indices (as well as
constraints) given a table's name, and to keep a record of this so as
to make restoration of these metadata possible.

With indices and triggers this is of course easy. Given the name of
the table my code traverses the resepective system tables and using
the data found there, it creates a script to deactivate the
triggers/indices and a second script to reactivate the
triggers/indices.

The reason this method cannot readily be applied to constraints is
that constraints can't be disabled or deferred from doing what they
do.

So I thought it might be possible to create a script to drop the
constraints on finding them (no problem here, assuming we drop them
in the correct sequence) and a second script to create the
constraints again.

The problem I am running into in constructing the second script is
that the relation_constraints table doesn't seem to store complete
information on the constraints. In particular, the FIELD or fields
the constraint is placed on. Or in the case of check constraints,
the search conditon. So I'm wondering: where is the complete
information? It must be somewhere...

Thanks,
Rob