Ann,

thanks for your answer.
I didn't lose information, so I assume it was an orphaned back version.
Nevertheless it is not clear what produced this pattern:

- The client (flamerobin) tried to apply an update on a table.
- The update was rejected because of a lock conflict (normal behavior
when other clients are also applying updates).
- The client did a transaction rollback.
- Any subsequent attempt to apply the same update hanged the client for
ever.
- Only solution: backup and restore.

Thanks,
Aldo

El 06/01/12 16:29, Ann Harrison escribió:

>
> On Fri, Jan 6, 2012 at 1:40 PM, Aldo Caruso
> <aldo.caruso@... <mailto:aldo.caruso%40argencasas.com>> wrote:
> >
> > "Summary of validation errors
> > Number of record level errors : 1"
>
> That may be an orphaned back version - a largely benign error that
> uses space but doesn't interfere with any operations. Unfortunately,
> gfix doesn't distinguish between serious errors and minor
> inconsistencies.
> >
> > 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.
>
> Fine. You probably did an unnecessary backup and restore, but the
> database is in better shape for it.
> >
> > Now my questions are the following:
> >
> > 1) Why and under which circumstances a client process can lock forever ?
>
> If you update or delete a record and do not commit the transaction.
> 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 service
> > produced a database corruption or loss of a table record ?
>
> Probably not. Crashing the server can cause page, record, and index
> 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 record
> > level problem ?
>
> Insufficient ambition on the part of the people working on gfix. It
> 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. Is
> > this normal ?
>
> If the error was an orphaned back version, a normal read of the table
> would be fine.
>
> Good luck,
>
> Ann
>
>

[Non-text portions of this message have been removed]