>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...

Do you mean that all operations which involve numbers (in this case simple integers) are faster comparing with char vars? What is logical versa 1/0 ? We currently have iActive_Flag in lots of tables...

>>
>>>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 ?

It's obvious it could be better to open all tables once. But it should be done in each particular batch procedure before calling any update data functions. Since I can not guarantee, it was done, I have to code around it. BTW, Steve's code does have all tables opened only once and he left them opened after the trigger finished. In my opinion, everything should be self-contained, e.g. if the procedure opened something, it should close it.

That was one of my questions in this thread, that Fabio and Gregory answered is not possible to achieve. My question was, is it possible to determine entry point and exit poin in REPLACE (or other commands) of this nature.

>
>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>.
>

He-he. I think my brain is boiling already after looking at this stuff for more than a week...

>>
>>>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
>

I have one procedure, which I use for my tests:

private glDontUpdateUserAndTime
glDontUpdateUserAndTime = .t.
lcFile = GETFILE('dbf')
USE (m.lcFile)
lnStartTime = DATETIME()
*SET COVERAGE TO TestPerf
replace cTrans_pk WITH cTrans_pk NEXT 50000
*SET COVERAGE TO
=MESSAGEBOX("File " + m.lcFile + " took " + ;
TRANSFORM(DATETIME() - m.lnStartTime,"@999.99999") + " sec.")

BTW, I was running another process at that moment and I just found out, that I made the same mistake again. E.g. I have a code SCAN while !empty(m.lcError). First time it works, but the second time it obviously did not because I don't have go top before that scan:)