Subject | Re: [ib-support] Re: check constraint stops working after backup and restore |
---|---|
Author | Helen Borrie |
Post date | 2002-09-13T09:48:06Z |
At 09:32 AM 13-09-02 +0000, Ian Newby wrote:
since it doesn't have the protection of a cascading FK...
Currently, the domain won't restore because the table referred to doesn't
exist yet.
If you change it so that the constraint was added after the tables were
restored, then any non-match would still cause *that* to fail. Check
constraints only apply when a new value is being given to the column that
has the constraint...which occurs during a restore.
If you want an existence cross-reference on a column and it can't be a FK,
do it with triggers to preserve integrity; or do it on the table column
itself if you must.
heLen
> > How could it? Restore has to create the domains before it createsEither way, the loss of the "matching" row would cause a restore to fail,
>the
> > tables, otherwise it couldn't create the tables.
>
>Although no currently possible, this could I believe be overcome
>with changes to the backup mechanism (and metadata extraction).
>Domains could be created without check constraints with the check
>constraints being added later, after the tables have been created.
since it doesn't have the protection of a cascading FK...
Currently, the domain won't restore because the table referred to doesn't
exist yet.
If you change it so that the constraint was added after the tables were
restored, then any non-match would still cause *that* to fail. Check
constraints only apply when a new value is being given to the column that
has the constraint...which occurs during a restore.
If you want an existence cross-reference on a column and it can't be a FK,
do it with triggers to preserve integrity; or do it on the table column
itself if you must.
heLen