mlq97 wrote:

> 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?
>
>

As others said, I do it at my production server, test it as usual, and
everything appears ok, then the changes would be applied to costumers.
Of course there is not 100% error free program

During the development phase I make an script to run all the needed DDL
(and/or DML) to upgrade a database, why don't you just make the same for
a reverse process ?

Note that there is some kind of modification that could not be reverted,
be it FB or not, be it Rails or not...

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br