> So - this is rather rare case when fdb file gets corrupted (there
> are error messages like 'wrong page number...', 'gds consistency
> check...' and so on) but - anyway - when this occurs then - up to my
> knowledge - there is not straighforward and realiable way for data
> recovery. 'gfix -mend' cann't always remove all the errors.
>
> From my experience - the only way is try to read as many healthy and
> available records from corrupted DB as one can (e.g. usually the
> primary key has datatype integer or sorted varchar and if only some
> data pages are corrputed then only some records around some special
> value of primary key are unavailable but the others are available,
> in very lucky case - the unavailable records are rather old and they
> can be read directly from some archived fdb files) and then - one
> should try to restore the lost records in other tables from already
> available data (this requires strong knowledge of underlaying data
> structure etc)...
>
> So - is any good design advice available how to design the 100%
> reliable solution with FireBird? As I know - Oracle has redo logs
> and any recovery can be done automatically. But FireBird hasn't such
> an option? So - one should rely on more hacked design choices. One
> option is try to implement custom log and then there are 2 choices -
> 1) write log in the same fdb file as the main data (with hope that
> there will be very low probability that both types of data - main
> and log - will be corrupted at the same time; 2) write log in other
> db file which can be located even in some remote HD. The second
> choice is rather expensive as multi-DB transactions are more complex
> than single DB. What else options can be?
>
> And at last - is there some ongoing progress in Firebird development
> to add more advanced recovery and logging features and are some
> activities planned for near future? Sometimes I feel that it would
> be nice to participate in development of such features as our
> company would be very interested in them.
>

IBLogManager offers write-ahead logging

Alan