--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 01:50 PM 10/04/2008, Adam wrote:
> >--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@> wrote:
> >
> >>
> >> Adam, have you ever seen the engine crash when gbak happens to read
> >corrupt data? Gbak -backup itself can crash but I've never heard of
> >the server crashing in these circumstances...did you attempt to
> >reproduce it?
> >
> >Yes. In fact with the one I have seen you can duplicate with an
> >unrestricted select * query on the effected table. I tried it again to
> >make sure I am not mad:
> >
> >.
> >.
> >.
> >.
> >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?

Adam