|Subject||Re: [Firebird-Architect] Feature Request: Domains in SP & Triggers.|
|Author||Ann W. Harrison|
>At 01:45 AM 10/8/2004, Dimitry Sibiryakov wrote:
>On 7 Oct 2004 at 14:02, Ann W. Harrison wrote:
> >Relation and field ids are designed to be specific only to
> >an instance of a database. Back it up and restore it and you
> >get another set of ids. That's a good thing. You'll find
> >that the BLR for procedure uses relation and field names.
> >System objects that are recreated (e.g. RDB$FORMATS and
> >RDB$PAGES) use ids.
> That's sad.I think we're having a language problem. Why is the use of names
vs ids sad?
> And it became even more sad because system tables don'tHow exactly would you create that relationship? And why is a
>have PKs. It means that I can't prevent user from dropping table that
>my application depends on.
foreign key necessary to keep your tables from being dropped.
We've got some problems with control over system tables, to be
sure, but I don't think that the absence of a declared primary
key on system tables is the source. You can, of course, declare
a foreign key on any field in the parent table that has a
> Can't create FK to system table. Not sureNot at the moment, if my memory serves which it often does not, but
>about triggers... If I create triggers for system table will they
>survive during backup/restore?
that can be fixed.
> IBReplicator is an example of application that suffer from thisWe should look at solutions for that.
>"feature". It'll crash if someone drop table for which there are
>pending operation in log.