| Subject | Re: [firebird-support] Validation problem |
|---|---|
| Author | Ann Harrison |
| Post date | 2012-01-06T19:29:42Z |
On Fri, Jan 6, 2012 at 1:40 PM, Aldo Caruso <aldo.caruso@...> wrote:
uses space but doesn't interfere with any operations. Unfortunately,
gfix doesn't distinguish between serious errors and minor
inconsistencies.
database is in better shape for it.
If the client exits without committing, it takes the server some time
to realize that the connection is dead and clean up after it.
errors because only one of two related changes made it to disk.
However, Firebird orders writes so that it never leaves dangling
pointers that could cause serious problems. Instead, it sometimes
leaves elements that can no longer be accessed.
knows the table id, but not the table name and the translation is
outside its area of competence. It understands the physical layout of
the database but not the logic, including the logic necessary to read
the system tables to get names from identifiers.
would be fine.
Good luck,
Ann
>That may be an orphaned back version - a largely benign error that
> "Summary of validation errors
> Number of record level errors : 1"
uses space but doesn't interfere with any operations. Unfortunately,
gfix doesn't distinguish between serious errors and minor
inconsistencies.
>Fine. You probably did an unnecessary backup and restore, but the
> I did a gfix -mend -full with the same result and a gfix -mend -full
> -ignore with the same result.
> I had no alternative than do a backup and restore to solve the problem.
> After the restore, a full validation gave no error.
database is in better shape for it.
>If you update or delete a record and do not commit the transaction.
> Now my questions are the following:
>
> 1) Why and under which circumstances a client process can lock forever ?
If the client exits without committing, it takes the server some time
to realize that the connection is dead and clean up after it.
> 2) Does this and / or the fact that I restarted the firebird serviceProbably not. Crashing the server can cause page, record, and index
> produced a database corruption or loss of a table record ?
errors because only one of two related changes made it to disk.
However, Firebird orders writes so that it never leaves dangling
pointers that could cause serious problems. Instead, it sometimes
leaves elements that can no longer be accessed.
> 3) Why the error message doesn't mention the table which has a recordInsufficient ambition on the part of the people working on gfix. It
> level problem ?
knows the table id, but not the table name and the translation is
outside its area of competence. It understands the physical layout of
the database but not the logic, including the logic necessary to read
the system tables to get names from identifiers.
> 4) Did I lose information ?Probably not.
> 5) The gfix -mend didn't work. Nevertheless the backup could be done. IsIf the error was an orphaned back version, a normal read of the table
> this normal ?
would be fine.
Good luck,
Ann