--- In firebird-support@yahoogroups.com, "Thomas" <thomas@...> wrote:

>
> Hi Eugen,
>
> sorry I made the assumption that you had already run GFIX. In my case
> even after GFIX had been run the problem still persisted.

Before attempting any recovery, you should shutdown the Firebird
service and burn a copy of the database as-is to CD/DVD. Sometimes
recovery can go pear shaped, so it is important to have this fallback.

Gfix should first be used, then backup-restore the database to confirm
this worked.

Often*1 gbak with -g switch can avoid the backup process to avoid
touching the corrupted record, so that can work also.

If all else fails, you may be able to recover some of the data using a
data pump tool. I have used IBDatapump with success. It involves
identifying the corrupted table (gbak will probably have failed on
it), then identifying the corrupted record. Performing a select with
an indexed walk, you can probably get the PK or the record that fails.
Build your where clause to deliberately avoid touching that record and
see if your select can return the whole table. If so, create a table
with an identical structure and do a insert into .. select from ..
query to retrieve the 'good' records. You can then map the new table
to your old table in a new database using your data pumping tool. Once
you have a successful data pump, backup and restore to confirm you are
in the clear.

If your corruption is just an index, you can normally drop the index
(or constraint) and redeclare it.


Adam

*1 By often, I mean relatively often compared to the number of
corruptions you receive. On reasonable hardware with forced writes
enabled, and without doing dumb things like file copies of an active
database file, we have never got corruptions. The only times we have
seen corruptions is with people not following the rules for handling
databases or hardware on its last legs.