> . transfer the data from the old database (direct transfer
> from old to new, no need for interim storage which can
> have problems handling blobs etc).

OMG, blobs. I completely forgot about blobs...:(

> . apply a "final" script that fully defines the triggers,
> procedures and other constraints.

Understood.
I was thinking of the 'empty' database as everything else except the
data, hence the original question. Maybe separating it into the three
stages that you outlined is better for the long run.

Because firebird doesn't yet support multi database queries, i'm
resorting to exporting the data as INSERT statements, which obviously
doesn't work with BLOBs... *sigh*.

> It simply copies a database, but the concepts and procedure
> are pretty much the same - indeed DBak can be used to do an
> upgrade with a certain amount of fiddling, because it allows
> you to split the processing and replace the database creation
> scripts.

Understood. Thanks for the link. Checking it out now.

> The transfer process in a real-life upgrade is not always a
> straight forward process - since you must ensure that new
> fields are completed appropriately and any change to
> constraints is appropriately managed during transfer.

ATM, If there are additional fields/etc on the new database, i'm
enforcing the new data via BEFORE INSERT triggers that provide default
values. This is completely different to the triggers that i wanted to be
disabled per the original question. Those triggers are mostly AFTER
INSERT/UPDATE/DELETE ones.

> Note: In any significant upgrade I would probably add some
> sort of validation/testing process on the end. Particularly
> if your normal backups use gbak, do a backup and restore to
> be sure that your new database can be survive a backup and
> restore cycle (that there is not some sort of data issue that
> will disrupt gbak).

At this point, the 'upgrade' process is completely separate from the
normal backup/restore maintenance cycle. But i'll keep that in mind.

Thank you,
t.s.