Subject RE: [IBO] update IBO$SCHEMA_VERSION from system table triggers
Author Michael L. Horne
I recall reading that there is a limit on how many changes
can be made to the metadata before a backup/restore must be
done. Maybe you could locate where that number is stored and
use it as a flag on whether to update the schema.

Maybe this could be combined with some other stuff to make it

I will soon need a good method to update the schema, I am currently
not using it due to the amount of changes occurring to the
metadata. My current plain was to have the programmer increment
a generator each time they change something in the metadata, and
having the program check the generator against a stored value. Not
great but that was what I was thinking of doing.

Good Luck

Michael L. Horne

> -----Original Message-----
> From: news@... [mailto:news@...]On Behalf Of
> Claudio Valderrama C.
> Sent: Tuesday, April 02, 2002 4:19 AM
> To:
> Subject: Re: [IBO] update IBO$SCHEMA_VERSION from system table triggers
> "Geoff Worboys" <geoff@...> wrote in message
> news:1533298078.20020402101649@......
> > > Are there any problems with this solution ? e.g. I don't know if
> > > custom triggers on system tables are restored after a backup &
> > > restore operation.
> >
> > As I understand it additional triggers on the system tables should
> > backup and restore OK.
> It's interesting to see what happens when one clicks randomly in a thread
> once per month on this list.
> :-)
> Additional triggers do not work on system tables.
> They will run after you created them.
> However, as soon as the last attachment is finished, the engine
> will unload
> that database (left out the garbage collection delay).
> When you login again, system tables' metadata is loaded from internal,
> in-memory structures or the engine will not be able to load any
> db (infinite
> recursion, chicken and egg, etc.) and this means only the known
> metadata is
> acknowledged. No extra field in system tables, no user trigger on system
> tables will be loaded. Your custom triggers won't work anymore
> although the
> information is stored in the db. The only cumbersome way is to do a dummy
> change to those triggers (like toggling the active state) that will force
> metadata loading from system tables but to be elegant, you would have to
> know this is the first attachment, otherwise do nothing.
> It's a logged limitation in the FB's bug tracker. Tricky and dangerous to
> solve.
> C.
> --
> Claudio Valderrama C. - -
> Independent developer
> Owner of the Interbase® WebRing