Thank you , I will also try to verify memory ( I know memtest , it's efficient the difficulty is that I am not behind the server but distant and it eed also to be run before Windows , not easy for my client ) .
But I think memory is not the problem for all , and after a repair the base usually work normally , if there was a memory problem the corruption would come back certainly and I would see some instability on the machien too , for now I have no case like that .
Have a nice day , regards ,

--- In firebird-support@yahoogroups.com, "Fabiano" <fabianoaspro@...> wrote:
>
> Try a program named memtest86
>
> It runs at system startup and detects defective memory modules.
>
> As you have minor corruption problems it appears to be a memory problem.
>
>
>
> Maybe a F8 in windows initialization have a memory test program too.
>
>
>
> De: firebird-support@yahoogroups.com
> [mailto:firebird-support@yahoogroups.com] Em nome de harveypekkar
> Enviada em: terça-feira, 31 de julho de 2012 10:33
> Para: firebird-support@yahoogroups.com
> Assunto: [firebird-support] Re: How to list the tables and field wich use
> the primary key from one table as FK
>
>
>
>
>
> Very nice ! the script list exactly what I need , thank you very much .
> About the influence about dev team I agree too , but they keep saying that
> the corruption problem do not come from update or new script , another
> problem is that our new deployement system work with patch , before we did
> backup/restore for each major update , that was a little constraint but
> there was less errors , at least corruption problem were discover before
> going too big .
> I hope to find someday the cause of corruption with no doubt about it source
> , for now i am not experienced enough to do this , I keep working on my
> repair tool and after that maybe I will find out why .
>
> Many thank for your help and Alan too , have a nice day .
> regards ,
>
> --- In firebird-support@yahoogroups.com
> <mailto:firebird-support%40yahoogroups.com> , Svein Erling Tysvær
> <svein.erling.tysvaer@> wrote:
> >
> > >I think you are 100 % right , the problem is that i am not working in the
> developpement team but in customer
> > >support , I suspect some software update to cause the problem but I have
> no access on that , the only thing I can
> > >do is to try to repair the best way for my client and I can't only
> validate and mend , I have also to put back the
> > >records from a backup with new ID or the problem will not be solve
> completely .
> > >
> > >We have about 500 servers too, the structure is from 2 up to 20 clients ,
> little workgroup under windows XP and 7
> > >
> > >I don't think the problem concern the firebird side , I know it's very
> strenght.
> >
> > You also ought to try to influence your development team somehow.
> Normally, it would not be OK for you to have 100 corruptions (assuming an
> average of 2 per week) when Alan hasn't experienced any corruption at all.
> Hardware problems and faulty UDFs used to be ways to make Firebird fail.
> >
> > The following may or may not help you:
> >
> > select i.rdb$relation_name, iseg.rdb$field_name
> > from rdb$relation_constraints rec
> > join rdb$ref_constraints rfc on rec.rdb$constraint_name =
> rfc.rdb$constraint_name
> > join rdb$relation_constraints rec2 on rfc.rdb$const_name_uq =
> rec2.rdb$constraint_name
> > join rdb$index_segments iseg2 on rec2.rdb$index_name =
> iseg2.rdb$index_name
> > join rdb$indices i2 on rec2.rdb$index_name = i2.rdb$index_name
> > join rdb$indices i on rec.rdb$index_name = i.rdb$index_name
> > join rdb$index_segments iseg on rec.rdb$index_name = iseg.rdb$index_name
> > where i2.rdb$relation_name = :MyTableName
> > and iseg2.rdb$field_name = :MyPKFieldName
> >
> > It is not tested, I know it does prepare and that it is possible to get
> some results, but I don't know if they are correct or complete (I'm assuming
> one field for each primary key).
> >
> > HTH,
> > Set
> >
>
>
>
>
>
> [Non-text portions of this message have been removed]
>