Thanks very much to Roman and Rick for answering.

> If I understand correctly, this discussion goes more or less
> in the direction of deferred constraint checks, though in
> that case check is delayed until the end of transaction,
> but not deactivated completely.

Yes, the deferred constraint checks describe definitely better what I
have to do. My purpose is to find a way to populate a target Firebird
database without having problems with referenced tables that still do
not exist (because they're still not written to the database at that
point in time).

> The talk is about a global switch that triggers all constrains
> inactive without a need to walk through all system tables and
> deactivating each constraint separately.

That will also suit my purpose: turn all constraints off, populate the
Firebird database without complaints about references to nonexistent
table columns, then turn the checks on as they have initially been.

> There are no trigger, it is checked by the corresponding index...
> which cannot be deactivated. So for now you can only drop constraint.

As far as I could understand, one suggestion to do this is to drop all
constraints and then create them anew. Is there a way to protocol the
existent constraints somewhere before dropping them?

> gbak has a switch that allows to restore database without validity
> checks. In your case, your application should do something similar...

What kind of switch is it? Could you please tell me if I can find the
source code for the gbak.exe somewhere in the CVS repository:
http://cvs.sourceforge.net/viewcvs.py/firebird/ in order to have a look?

> > ALTER TABLE <table name> ALTER CONSTRAINT <foreign key name> INAVTIVE
> > Dynamic SQL Error SQL error code
>
> Sure, this construct does not exist yet

But I thought initially that the error was due to the misspelled
"INACTIVE".