At 11:29 PM 24/08/2007, you wrote:

>Hi,
>
>I ran out of disk space while updating a Firebird 1.5 database (size
>about 0.5 GB).
>
>I am able to open it (using database workbench), but cannot access
>the main (largest) table below a certain point) nor can I do a select
>count(*) ... from this table.
>
>When I run GFIX and look into the firebird.log file, it seems to
>continue looping while trying to fix the db: it shows a large number
>of messages: Page 60000 double allocated (with page ranges between
>60000 and about 69800 - about every 5th page show this error).
>
>Than it produces one Index corrupt error on the last page number:
>'Index 1 is corrupt on page 69751 in table STATS (136)'
>and than restarts the double allocated error messages.
>
>Is there any way I can fix this database (apart from restoring it
>from a backup) ?

Gfix can't repair structures that are physically broken, as would be
the case here, where the engine has been denied a request for a new
page on which to write index data or indirection data. If data pages
are damaged, there are ways (complicated) to recover some damaged
data...if you are lucky and Firebird 1.5 has behaved nicely, you
won't need to go there.

If you don't have a file copy of the sick database then STOP NOW,
make certain nothing is connected or trying to connect, make a file
copy of that database and move the original to a safe place. Do your
recovery attempts on the copy (on a disk that has plenty of space
available, natch!!)

What you have currently is a database that is corrupted to an unknown
extent, but you *can connect to it*, which is good. If you are
lucky, then the only thing broken is Index 1. Dropping and
recreating the index should fix it - but PLEASE make sure that you
have plenty of disk space available. (If it is a constraint index,
you will need to drop the constraint.) I suggest you work via ISQL,
rather than a fancy utility like Workbench that might rely on that
broken index for something unrelated.

./heLen