> You can't make changes to the structure of the system tables that
> would survive a backup/restore but it was interesting to muse
> whether triggers might survive. I don't know if they do, but why
> not test that? If it worked, at worst you would have confirmed a
> vulnerability; at best, you would have found a route whereby you
> could set up a "versions of everything" table that was maintained
> by after triggers (with very high "position" numbers) for each of
> the system tables that gets DML hits as a result of DDL changes.

Helen,

There is probably something to be said against basing ones database
version identification on something that could be considered a
security flaw. It will inevitably be broken by a future update ;)

Myles,

Our databases have a table that hold a patch number. Each of our
database changes inserts its unique patch number into this table. Our
upgrade application extracts all of the patches to a temporary folder,
queries the database to determine the installed patch number, then
applies (in order) the patches that have not been run. It does a bit
more, like renaming the fdb file to ensure exclusive database access
before it starts and takes a file system copy (of the renamed database
that no-one has connected to) to allow a quick back-out should any
problems occur.

Your application can easily determine whether the database is at a
sufficient patch level to run.

Adam