Jason wrote:

>1. We're using the latest OpenSource Interbase (6.0.1.6 Open
>Edition)...

OK, that version has that problem.

>2. Exact error message is, when trying to open this database with a
>client (IBConsole is what gave us the following message), "IO Error
>for <filename>. Error while trying to read from file. Reached end
>of file."

That's probably a missing TIP. Do you run with forced writes enabled?

>3. The customer had a "backup" system in place...

Do encourage them to use gbak to produce the file that they put on
their backup medium. Gbak does not require taking the database off-line
during the backup and tends to clean up little pieces of lint that
build up in the database. If they are copying a running database to
their backup, then they are almost certainly creating corrupt backups.

> > You're running on a windows operating system and
> > you're using different connect strings for different clients.

>After discussing more with our support people, I've found that we are
>definitely doing this.

Ouch.

> > The best solution is to convert to Firebird RC2, which will detect
> > that problem and prevent the corruption.

>Solution 1 is something we'll be discussing. However, our concern is
>when Interbase and Firebird diverge enough that components to access
>one won't work to access the other (Specifically Interbase Express).
>If there are going to be IBX components to do the same job, with at
>least the same performace, then we're fine.

Absent some deliberate efforts on the part of Borland and their
allies to sabotage the interface, Firebird and IBX should work
together for the indefinite future. Such an effort is unlikely
because it would also sabotage Borland customers running older
versions.

> > The "end of file" error occurs because the system is looking for a
> > transaction inventory page (80% probability) that did not get
> > written.
>
>We were getting the end of file error, before we started hex editing
>the header of the gdb file.

That's a common symptom for this particular error.

>When we started playing with transaction counters, we were
>decrementing them, not incrementing them, on the assumption that if
>we could get back to the last "good" transaction, we could then use
>the gdb file from there, with the amount of data that could be "seen"
>and whatever was lost was the client's fault, because of their poor
>backup procedures.

That's actually somewhat backward, though incrementing the counters
has it's problems. One reasonable thing to do is to set the database
to be read-only, then increment the counters. The problem is not that
there are "bad" transactions that

>My question is, if all of the restore procedures that have been
>outlined previously don't work, is decrementing the transaction
>counters like this, to get to the last "good" transaction in the
>file, a valid approach to take to repair this file and get the
>customer back up and running in the short term (Probably with a
>gbak/grestore after the gdb file can be opened, so we have a clean
>gdb file)? Will there be issues that are not immediately obvious
>(Aside from the loss of data that's almost sure to result)?

Here's what I do. Set the database to read only, using a hex-editor
if necessary. Scan through the data, looking for the highest
recorded transaction id (see ods.h for a description of the format
of a data page and a record). Set the next transaction to be higher
than that, and if necessary create a new TIP page (see ods.h again).
Again, if necessary, set the state of transactions on that page to
committed. Finally, do a backup & restore.


Regards,

Ann
www.ibphoenix.com
We have answers.