BTW, this m.lcTriggerType thing is used properly in the code, because it is in

case m.lcTriggerType = "UPDATE"

statement < g >

So, one less problem to worry about :)

>Hi Nadya,
>
>>>a)
>>Since I generate that table, I can easily use 0 for Ignore, 1 for Restrict and 2 for Cascade. Do you think, it's better?
>
>The operations (assigning, comparing and passing to functions) should ALWAYS be faster - between 10 and 30%. BUT I guess the total cost of these operations (especially when NOT run in the profiler) is less than 10%, so check before changing. You have the numbers...
>>
>>>b)
>...
>>Sounds good, I'll make that change.
>Thought so...
>
>
>>>c)
>
>>I need to think about this one, but sounds good as well.
>I think this one is the best: exchange for code for some doc and get better speed as well.
>
>>
>>>d)
>>>in the lowest functions you check for open tables and, if necessary, open them. Closing is offloaded to cleanup (haven't checked too closely) - might it be a good idea to have a openup previously/AndOR leave always open and eliminate the check in the lower functions ? This you should check from your coverages.
>>>
>>
>>Open before the call - right above the Restrict_Update. Sounds good to me too.
>
>No, I meant considering to open the relevant tables if possible only once. I haven't tried to follow the code exactly, but there was a session object involved. Is it possible to keep the tables open in this isolation during the whole runtime of the app or the isolated form ? Open on first need for RI and close at the very end ?
>
>e)...
>>UPDATE. We can get rid of them, but we'll loose readability...
>
>Feared so. Keep it as it is, and if after the very end of your efforts and 3 months of failure free usage you need another small boost, then change. Never touch again <bg>.
>
>>
>>>and lastly: m.dotting on the left side of an assignment is unneccessary and even COST nanosecs <bg>

>>>m.lcTriggerType = 'UPDATE'

>>>
>>I know this one. Did something like this slip into my code? I'll check it up.
>Snipped from the code you posted ;-)
>
>>Thanks a lot for valuable advices. These are easy to implement, so I may try then right away and see the speed difference, if any.
>
>Hmmm, that's part of what I meant by being too close. You should have a mental picture of the weight of each part by now. Assumed you've timed with and without the profiler you should be able to estimate the effect on your test cases according to the figures you already got from your testcases. If you try out the hints just in timed loops (doing nothing else), you'll get sizable differences, but most of the time there are more important bottlenecks to be found in actual working code, which translates to the effects being less spectacular than in the pure test loops.
>
>If you are certain to have a production-safe errorfree version AND a test scenario including batched test cases, I could view the timings/weights and perhaps find another angle.
>
>HTH
>
>thomas