>>>I want to maximize the speed of performing calculations in related tables. I will be performing a REPLACE on every record in the child table based on values in the Parent record. Any thoughts on the best performers ?
>>>
>>>1) Using Set Relation to 'automate' finding records in child tables
>>>
>>>2) Using Set Filter to 'manually' SKIP thru records in child tables based on Parent key.
>>>
>>>3) Using Scan For in child table based on Parent key.
>>>
>>>4) Using good old fashion Seek in the Child table based on Parent key.
>>
>>Hi Peter,
>>First of all I think a REPLACEMENT for REPLACE would be faster. If calculated and replaced fields won't be edited setting a view would be the fastest. If in your case REPLACE is a necessity :
>>1) Set filter is worst. I better think this command had never existed. If you use it, you would add extra workarounds for optimization. ie: set order tag and locate - instead of go top or set order tag descending and locate for go bottom... etc.
>
>Actualy, SET FILTER works quite well if its expression is Rushmore optimizable.
>
>>2) Set relation was good in old days. But in buffering modes you don't get your relations as simple.
>
>You mean?
>
>>3) scan...endscan is highyly optimized, but *for* slows down it.
>
>*for* doesn't slow down a SCAN. At least not if the expression is Rushmore optimizable.
>
>>4) Seek as in good old days still is the fastest. Combining seek and scan while...endscan could be best performance.
>
>Actually, in many cases, Rushmore optimized SCAN FOR is much faster than SEEK + SCAN WHILE. In order to achieve the best performance you should SET ORDER TO in child table (ie: no order set during the SCAN FOR).
>
>In fact, the best performance between SCAN FOR and SEEK + SCAN WHILE depends on: physical layout of the table on disk, the network type/load, the dbf type (the average number of child records for each parent record), the application type (massive data enter vs. massive data interogation).
>
>My opinion is that "usually" SCAN FOR is the best choice. But you must test for your self both solutions.

No one has mentioned the SQL UPDATE command. Why not
UPDATE table ;
SET field = newvalue ;
WHERE childkey = parentkey

I do believe that this is RUSHMORE optimized and ought to work quickly.

Steve