> We have experienced out first database corruption from any of our
> customers
> in 15 years of Interbase and Firebird!
>
> I would like some clues as to what may have caused it.
>
> FB 1.5.3, windows server 2003, superserver
> The databases appeared to backup without problem. On restore they
> would
> fall over with 'string truncation . . . ' error on 2 foreign keys and
> violation of not null constraint on a primary index. Dropping and
> replacing
> the indexes didn't fix it and there where no null values in the table
> with
> the primary key problem.
>
> I forgot about GFIX having never had to use it before so I have no idea
> if
> it would have helped.
> I was able to fix the databases by backing up, restoring with
> 'deactivate
> indexes' and 'don't enforce validity conditions', then running a small
> program to activate the indices one at a time. When it reached a bad
> one it
> reported it so I could then remove it and use the program again until
> all
> good ones where active. I then reinstated the removed indexes and was
> able
> to backup and restore normally.
> At first I thought this might have caused by ill advised windows
> copying of
> the live database files which may have been locking mid way through
> index
> pages ( quite prepared to admit I could be talking rubbish here ) but
> the
> strange thing is that there are 2 databases with identical structures
> and
> different data. However since one primary key and 2 foreign keys where
> commonly corrupted in both databases it seems a less likely candidate
> (and I
> have no evidence copying happens anyway).
>
>
>
> Another thought was updating database structures using the scripts
> created
> by ib_expert database comparer. However one of the indexes corrupted
> in
> both databases hasn't been changed for many years. Whether this could
> have
> been cross contaminated by something else I have no idea. There is no
> access to files for the virus checker, there has been no messing with
> system
> tables (other than a few tricks in the database comparer script) and
> there
> is plenty of spare disk space.
>
>
>
> Any idea what could have happened to the indexes?
>
> Would GFIX have made the fix easier?
>
>
>
> Best regards
>
> Paul
>

had something similar a long time ago.
I'm sure it was hardware related. In my case it was faulty RAM.
I since have services which email me on bootup. I can see when a server
re-boots. If it's not intentional I give people a roasting til I find out
who or what did it.
If it happens more than I expect, then I give clients a hard time about
their faulty hardware.
Other than that - I would first suspect metadta updates while users are
active. I always make sure I'm the only one on board when I do this.
It's always good to peruse the IBE script. And I alwas have a target DB
which I am using for my compare in the first place, to run the script on
before I script the production DB. I've never had issues with IBE compare
scripts. I do mmultiple servers updates when I do them.
Alan
PS - GFIX could have helped but your method was still the same (correct)
outcome.