>> The log tells you that an index in various tables (ITENSVENDAS,
>> SAIDANOTAS) are corrupt.
>>
>
> yup!
>
>> If you query the system table RDB$INDICES with a WHERE clause on
>> RDB$RELATION_NAME, you can get a list of indices. The result set also
>> includes a RDB$INDEX_ID field, although I can't recall if e.g. "Index 3
>> ..." on a particular table is the index with a value of 3 in this field
>> or 4 (starting at index 0 or 1).
>>
>> Try to drop the indices in question and re-run a validation. As Firebird
>
> RDB$INDEX_ID always start from 1. Not sure thought that gfix returning is also starting from 1. So I'm trying deleting all now...
>
> Found that I can't drop two of the 8 Indexes. But deleting them now I can gfix the file and run gbak after. Thanks.
>
>> 2.1.4 has some index corruption issues fixed, I would also run a
>> backup/restore cycle with 2.1.4.
>>
>> Hope this helps.
>>
>>
>> --
>> With regards,
>>
>> Thomas Steinmaurer
>
> Helped! ^.^
> I was just with many things in my head that I did not tried to delete the indexes.
>
> Anyway, what I was really concerned is that run gfix in the database file causes fbserver.exe to crash every time...
> This is potentially hazardous if there any others connections in opened.

True for SuperServer and SuperClassic in 2.5. Although, to validate a
database, you need exclusive access, thus no other connections to the
database are possible. So, if there is only this database under control
of the server, then it isn't that bad. ;-)

--
With regards,

Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/

Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!