>Hi Nadya,
>
>a few thoughts from just glancing over the code. The original code was written from a "book" perspective to teach good coding standards. But if necessary (batch updates of a few million records, webserver getting hammered by a few thousand people per hour) this code could be made leaner at a minimal cost in readability (but remember my lines about premature optimization before implementing!).
>
>a)
>you use easy human-readable alternatives in your code

>m.lcTriggerType = 'UPDATE'
>
>lcRIInfo = UpdTrigger
>if not empty(m.lcRIInfo) and m.lcRIInfo <> 'I'
>

>which is slower than working with numerical constants. You'ld have to wheigh the ease of glancing over RI table with string identifiers against code running always slightly slower. If you define a second table "translating" numerical keys into easily readable identifiers and inspect the RI-table via a view referencing both tables, you should have the best of both worlds: ease of developing and speadiest RI-code. You have the numbers to decide if RI code is called that often to necessitate that effort.
>

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?

>b)
>In some functions there is a check on one of the parameters to decide if anything should be done.
>First of all, defining "local lctable" should be inside the if, since it is unnecessary if the check fails. Secondly (*if* coding for pure speed): function overhead in vfp is quite bad, and it gets worse with each parameter passed (double that for string parameters!). If IsNull(m.tuOldKey) is true for a sizable percentage, it is speedier to check this condition just prior to calling the function Restrict_Update(....) since the call overhead is eliminated.

>
>function Restrict_Update(tcParentTable, ;
>	tcChildTable, ;
>	tcParentKey, ;
>	tcChildKey, ;
>	tuOldKey, ;
>	tuNewKey, tcTag)
>local lcTable
>
>if not isnull(m.tuOldKey)
>.....
>endif
>return

>

Sounds good, I'll make that change.

>c) again the cost of parameter passing: How about feeding the table values directly into the function call OR use privates to save the table values in and don't pass them ? Since there are no deeper levels, with some documentation for the need for speed it should be safe and clear.
>

I need to think about this one, but sounds good 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.

>e)
>if the "lowest" functions are shortened as described above and are called only once, why put them into their own functions ? The code is not *that* difficult <g>
>

They are called lots of times, so I don't think we can get rid of them. I'm not also one 100% sure I can get rid of parameters. They are different depending on the place the function is called.

UPDATE. We can get rid of them, but we'll loose readability...

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

>Those optimizations are "micro"-optimizations and probably will show measurable effects only if all your expensive table searches/scans are optimized to the limit. Even then, caching the most often used searches might give better results than the above hints: you have the numbers to check against.
>
>my 0.02 EUR
>
>thomas

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.