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.
Is there another update on system tables which makes this table persist? Is the backup process dominated by a hardwired list of system tables? Or is it the restore which ignores this table?
Ann W. Harrison answers:
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.