At 03:02 PM 10/04/2008, Adam wrote:

>> >gbak: writing data for table [CORRUPTTABLE]
>> >gbak: ERROR: internal gds software consistency check (wrong record
>> >length (183))
>> >
>> >gbak: ERROR: gds_$receive failed
>> >gbak: Exiting before completion due to errors
>> >gbak: ERROR: internal gds software consistency check (can't continue
>> >after bugcheck)
>> >
>> >In firebird.log
>> >
>> >LAPPY Thu Apr 10 13:32:58 2008
>> > Database: F:\BACKUP\DATABASE\OTHER\CORRUPT.FDB
>> > internal gds software consistency check (wrong record
>length (183))
>> >
>> >I have also seen one other instance where gbak failed due to the
>> >corruption but was successful with the -g switch (corruption must have
>> >been in a back version).
>>
>> Cool. ;-) Are you able to report it in Tracker, along with engine
>version number and a zipped copy of the database?
>>
>
>Helen,
>
>Unfortunately it was a customer's database. There is some sensitive
>data inside (other) tables. Normally I could overwrite this data and
>backup/restore it out, but obviously that can't work ;)
>
>I know how the corruption occurred (sys admin mishandling files while
>the server was running), and managed to use a data pump at the time to
>recover pretty much all the data.
>
>Is there any process I can sanitize this information, or
>alternatively, is there any way to reliably cause such corruption so I
>can duplicate it on a non-sensitive database?

I think it would be enough to provide the ODS number of the database, along with the exception messages, and describe as well as you can how the data got corrupted. Better that, than it would go unheralded. ;-)

./heLen