> Here's my formula for database self-help.
>
> 1) copy the database
>
> 2) run gfix -v -n to determine the extent of the problem.
> Keep the results.
>
> 2) attempt a gbak -v -b -g <database> <backup>
>
> If that works, restore the database. Gbak doesn't read
> user indexes, so it won't stop because of index errors.
> The -g switch keeps gbak from trying to remove old versions
> of records, so if it ignores corrupted back versions.
>
> 3) if that fails, run gfix -v -m to try to remove areas
> of corruption.
>
> 4) backup and restore the result, and compare it with what
> you expected to find.
>
> 5) if that fails, try using a data pump to move data to a
> clean database. If there are remaining corruptions in a
> particular table, you can often figure out which primary
> key values lead to bad records. Pump everything lower than
> the corrupt value, then everything higher. Hope you can
> find the missing records in a backup.

Ann, thank you for the truly wonderful response. I appreciate your reassurance about the resilience of Firebird. I especially appreciate your detailed discussion of how gfix "mends," and your step-by-step suggestions for a repair procedure. I will do my best to use that as a guideline in the preparation of a GUI repair "front-end" if possible.

There are a few places where you say: Do "A". If "A" fails do "B". If "B" works, do "C." Is it possible for a Delphi program to determine failure or success of the steps you've outlined, or does this actually require human intervention? For example, can my program parse some kind of log file and then act accordingly?

Perhaps a parallel, more specific, question is: When I run gfix -v -n, is there a way to get the result such that I can parse it? I've tried a simple pipe into a .TXT file, but my syntax may not have been correct.
gfix -z -u <username> -p <password> <Database> | <destination file>

BTW, I used -z because -i -v produced no result. I assume that was because my database was okay.


Again, Thank you so much for your very informative reply.