> PS: Or, if anyone has a simpler/better/faster idea on how to
> 'upgrade a production database', i'm all ears. Thanks.

The idea is essentially this...

. create a new database with just enough to support creation
of the table definitions

. 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).

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

Take a look at DBak.
http://www.telesiscomputing.com.au/dbk.htm
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.

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. If you
dont do that then the final phase of the process is likely to
fail with data integrity issues, or your new database may be
left with data that would not have passed the validity
constraints of the new database triggers etc.


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).


HTH

--
Geoff Worboys
Telesis Computing