At 03:13 PM 21/03/2008, you wrote:

>I have a Firebird database that I'm going to be including with a product
>that we sell. The database is used as a data warehouse for nightly "kill &
>fill" from a transactional system. It also includes a lot of documentation
>as to the data model, data dictionary, etc. which has been all created in a
>CASE product.
>
>I need to be able to define within the FB database, a version number
>associated with the schema that was used to create the database. This way I
>can be sure that we are shipping the correct DDL for the documentation.
>Since users won't always upgrade at the same time, I will likely have lots
>of previous versions in play and there will come a time when the
>transactional system will not be able to dump its data to the data warehouse
>because the data warehouse won't support key tables/columns that are needed
>for reporting.
>
>Has anyone found a way to version stamp the DDL within a Firebird database?
>I can certainly do this with scripts that would build the database, but I
>was hoping that since this is a Windows only product, we might be able to
>ship a backup file or even a FDB file with it so that the user can get up
>and running faster than having to run a script.
>
>Any thoughts?

Funny you should ask...I was having a light-hearted discussion not long ago with someone about how you might be able to "trojanize" a database by creating user triggers on the system tables. 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