Hi Nadya,

> I re-ran it again and now it takes 87 sec. for 50000 recs. Did I do something bad again? It's like 1 step forward and 2 backwards... :( And I hadn't yet tested everything in my test database.
>
>I did a test with my TEST database first using yesterday's code. It took 13 sec. Then with today's code. It took 17 sec. I guess, I'm running in the wrong direction...

Hard to say and definitely peculiar. When faced with fluctuating measurements I ususally advise to create a special totally empty partition and to generate a script always cleaning the partion and copying data into it before each run, to give a constant base. But differences of that magnitude are seldom caused even by fragmentation/full disk, and since the test is only updating existing data tables this argument/way to go seems even less likely.

Probably the first order of business is to build a small protocolling test harnass, which picks up any global flags used to modify behaviour and protocols this with the times taken - simple StrToFile() appending is usually good enough. You do have a SQL - statement verifiying the correctness of pdate run ? Perhaps a counterswitch to optionally update a global array with the number of times RI itself is called, each of the lower RI-functions is called, and what _tallies were gained in the cascades, perhaps even discriminating the _triggerlevels as rowindex for a 2-dimensional view of the RI-generated actions.

Another way to slice the info would be to analyze the coverage: the the total number of lines called / log size should be lower, but the call frequency for each method should be constant. Differences of that side make me think more about transaction / table opening differences, if the code ran flawless.

Not enough data here, sorry.

regards

thomas