Of course there is nothing inherently wrong with DDL scripts executed when
upgrading an application, but this is rather different from executing DDL
whenever a value is inserted into a table. DDL when inserting just feels
like mixing two very different things. Using multiple tables is fair
enough, but again - automating this to happen whenever a value is inserted
in another table isn't quite ideal. Firebird isn't that 'object driven' yet.

Set

At 20:48 03.03.2003 +1100, you wrote:

>Set,
>there's nothing inherently wrong with DDL scripts AFAIK. Maybe I'm silly,
>but when I pass out an upgrade to my applications, the minor version number
>increase coincides with a metadata upgrade to the database. Everytime my
>applications fire up, the first thing they do is check the version of the
>database. If the application is a (or more) step(s) ahead, then IB_Script
>components fire up to upgrade the database and commit the changes. Since
>these scripts are left in the source, it is possible then, to bring a
>database several versions old up to date in one transparent step. There is,
>of course a note and my users are aware that an upgrade must be done while
>noone else is working on the database. But I haven't had a problem with this
>strategy yet.
>In Duilio's case, I would rather do it with multiple tables. Since no two
>companies are allowed to see other company's data, then separate tables
>would be ideal - especially since permissions would be easier to manage. But
>it's his project.
>Alan