Stephane,

>
> i m so happy that you are here with your help !

Err, I'm not very helpful, but I'll assume that's not sarcastic...

>
> i m sure that it's not connected to the memory probleme (force write is on),
> because these bug appear just after i update the schema of our database.

Post hoc, ergo proctor hoc? OK, lets continue with that assumption...

>
> i split one table with 12 index in 40 tables with 2000 index (and add 10 times
> more row in it at the same time).

What does gstat say about the indexes - depth, number of nodes,
compression, etc.?

>
> strangely few day after that we start to
> have database corruption :( our database is very intensive (we have around
> 500 fb_inet_server.exe open every time for example).

I'm guessing that you've got tons of reads and almost no writes.

>
> also adding or deleting row to these 40 databases is a very low process. do
> you think i can pass the pagesize from 4ko to 8ko can help ?

Adding and deleting are "low" meaning there isn't much, or "slow"?
That depends on what gstat shows. As long as the index depth is
not more than 3, then increasing the page size won't help much.

>
> also do you thing that the superserver could be better than the classic
> server on such bug? or i can wait firebird 2.5 (when it's will be

available) ?

>

Are your bad nodes all level 1? Are any level 0?

Do you have any evidence, other than the gfix validation, that the index
is not working correctly? Are you getting the expected results? Gfix
validation is sometimes fussy about things that really aren't problems.


Cheers,

Ann