>
>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.

At 01:45 AM 10/8/2004, Dimitry Sibiryakov wrote:

> 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't
>have PKs. It means that I can't prevent user from dropping table that
>my application depends on.

How exactly would you create that relationship? And why is a
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
unique index.

> Can't create FK to system table. Not sure
>about triggers... If I create triggers for system table will they
>survive during backup/restore?

Not at the moment, if my memory serves which it often does not, but
that can be fixed.

> IBReplicator is an example of application that suffer from this
>"feature". It'll crash if someone drop table for which there are
>pending operation in log.

We should look at solutions for that.

Regards,


Ann