Alan McDonald wrote:

> If I do this (after creating an ordinary table):
> UPDATE RDB$RELATIONS SET RDB$SYSTEM_FLAG=1 WHERE
> RDB$RELATION_NAME='MY$ORDINARYTABLE';
>
> I end up with a table which is not immediately visible in the list of tables
> but accessible in all other ways. It does not, however, persist a
> backup/restore cycle.

Ah. You have hit on an ancient architectural flaw in Firebird,
InterBase, gds/Galaxy, Epic, and their inspiration Rdb/ELN, born
as JRD.

All those systems (well, both of them since the first four are
names for the same evolving code, use active system tables.
What I mean by 'active system tables' is that when you commit
a change to a system table, the object described springs into
existence. An interesting, but not terribly useful idea.
What would have made it even better would be if the active
system tables themselves were created from a core set of
active tables and fields, so you could extend them dynamically.
Didn't happen.

In fact, the database code knows what's in the system tables,
explicitly and completely. When you create a database, every
system table element is created. Gbak knows that, so it doesn't
backup anything marked as system.

>
> Is there another update on system tables which makes this table persist?

No, alas.

> Is the backup process dominated by a hardwired list of system tables?

I believe that it's the backup side that ignores anything marked as
system. If that were changed and restore were tested, it might be
possible to add triggers to system tables.


Regards,


Ann