Helen Borrie wrote:

> At 09:10 PM 10/03/2008, you wrote:
>
>> The database for an application keeps getting corrupt and i can't find
>> the reason for this
>> I'm using ibpp for connecting to that database and the exception
>> reported by that api is:
>> "Internal gds software consistency check (decompression overran buffer
>> (179), file szq.cpp line 223)"
>>
>> I can fix it with gfix and gback but it keeps "resurfacing" and i'm
>> lost. The problem is that i couldn't replicate it on my test machines
>> but every now and then (this is like the 8th time ) the client reports
>> this error.
>>
>> Can you give me some point of direction as to were to look for answers?
>>
>
> Forensics! In particular, look for things that humans do...
>

Forensics indeed :)

> Is the DB server running on Windows with forced writes off? (It should not be but can you be certain there is no site user with sysdba access who might have done this?)
>

I think it runs with forced writes off but i'm not sure (it runs on
windows). I'll have to go there and check, right?

> Have you checked that database with gstat -h to ensure that it does not have a higher ODS version than the installed server can deal with? e.g., If you are using Fb 2.0.? the ODS must be no higher than 11.0, if Fb 1.5, the ODS must be 10.0 or 10.1...and so on. (gstat -h will also reveal the FW setting).
>

Server is FB 2.0 and ODS 11.0

> Another possibility is that the database was moved from a different platform by file-copying, or that it has been file-copied from one filesystem format to a different one on the same platform, e.g. NTFS to FAT32 (or vice versa); ext3 to ReiserFS (or vice versa).
>

Could it have to do with some stupid antivirus that scans the file while
user commits transactions

> As an example, if you restore the database in a FAT32 partition, test it and then file-copy it to replace the wobbly database on an NTFS partition...
>
> It won't hurt to verify that all your indexes are active and to eliminate the possibility that users are logging into the database during a restore.
>
> etc.
>
> ./heLen
>

Thank you for your reply,
Eugen