> The classic way of changing schemas seems to be unidirectional and to
> assume that all sequential upgrades will be stable and OK.
>
> If they turn out not to be OK, the previous schema and data must be
> restored from a backup, thus losing all data changes since the backup.
> This seems very unsatisfactory because the schema error might not be
> detected for some time and substantial data loss might result.
>
> In Rails there is a standard methodology for downgrading schemas as
> well as upgrading. It applies a "reverse upgrade" to an existing live
> database by reversing the schema changes applied in the last upgrade.
>
> 1. Although this is also undesirable, is it not a better way of
> handling this, as it potentially avoids losing the new data?
>
> 2. Does anyone do this with Firebird? If so, are there any tools to
> help with this?

I've been doing it this way for years. I always apply the schema to a db
copy (and test it there) before applying to the production version.
I've never had to restore a backup under these instances.
What case are you thinking of with regard to schema error?
Alan