Hi Jim,

Thanks for your reply!

Jim Starkey wrote:

> It was designed to do just that. The problem is that gbak never got
> fixed to backup and restore extensions to system tables. And, I'm
> afraid, gbak never got fixed because it's significantly non-trivial.
>
> Now, all that said, when I had to do the whole thing all over again, I
> made system tables not only non-extensible by users, but completely
> non-writable by users.
>
> Even though it may be possible, I strongly urge you not to extend the
> system tables. Set up parallel but separate tables and save yourself a
> great deal of grief.
>

Very interesting.

In my case, I do indeed use my own parallel tables (since there isn't
any other option), and I can understand that it probably wouldn't make
sense to introduce a tricky feature into the engine considering that it
would only seldom get used. Besides, at least that way the exact
structure of the system tables can be counted on.

In that case, I would be interested to see at least triggers working on
system tables, if, again, that doesn't cause too big of an upheaval for
gbak. That would allow those of us who would have had a use for custom
extentions to the system table to have something almost as good: the
ability to automatically keep in sync a parallel table with the real
underlying one by using triggers. Triggers on the system tables would
also, of course, make logging meta-data changes very easy (whereas now
it's hardly possible).

Anyway, I guess this is a bit of a minor issue, and perhaps not worth
putting a lot of work into.

--
Best regards,
Jonathan Neve
_______________
CopyTiger - advanced database replicator for Interbase/Firebird!
Web : http://www.microtec.fr/copycat/ct
_______________________________________
CopyCat - database replication components for Delphi/C++Builder!
Web : http://www.microtec.fr/copycat/cc