> I reproduced such corruption with your test and i saw that page at level 1 missed down pointer to the leaf level. It is *very* likely because engine was unexpectedly stopped during propagation of just splitted leaf page pointer to the upper level. Unexpected stop happens because of "invalid lock id" error.
>
> I.e. i have great hope that all index corruptions as above will disapear when we fix "invalid lock id" error. And i expect to fix it in the next few days, at least i'll be able to prepare custom build for you.

VLAD YOU ARE THE SUPER HEROE :)

I disable the monotoring table from today! also i thing too that the index error appear after "engine crash": the "write" process is a very long process as you probably notice in the test, because lot of index need to be update ... and for every insert / update lot of megabytes are written on the disk, so if the engine crash their is a huge probabylity that some 'written' was in processing ...


just one remark, i notice that in the last version of FB2.5 in the current snapshot, when engine crash it's not always have an error msg in the firebird.log .... i say that because mormally the database use around 25 GO of memory, and sometime when i connect i see it to 4 GO only (but growing), making me thinging that firebird server crash without writing anything in the Firebird.log... can you confirm it's possible?

> Right now i recommend you to remove (or disable) your monitoring code and look what happens. If you strongly need to find slow queries it is much better to use new tracing facilities of FB 2.5 for this purposes.

yes i will do this and it's will be a good test to know if the index corrupted appear again. about the new tracing facilites of FB2.5 i will need some doc about it ?

thanks you by advance
stephane