Hi Paul,
I had a surgery and wasn't around for along time.

>>2) Set relation was good in old days. But in buffering modes you don't get your relations as simple.
>You mean?
I mean without tableupdate etc your relation needs a workaround.
Simple. Just set relations and use buffering. Than in a grid use a controlsource from childtable.
ie: parent.emp_id = child.emp_id. Enter emp_id and watch child.name.

>Actualy, SET FILTER works quite well if its expression is Rushmore optimizable.
Quite ? Oh no just well maybe. If you say it does the job than it's OK. I meant the speed.
>*for* doesn't slow down a SCAN. At least not if the expression is Rushmore optimizable.
Oh sure it does. In theory it should and in practice it does. All in harmony. This is called
*quite well* ?
As you say "at least not if...".
It would be fastest with *for* if...if...if... and if could be use with *while*.
Rushmore optimization ? This would be long subject. just think how often you use it.
I think you also write code already optimized.
Try setting so many tags and execute a ;
SCAN...ENDSCAN with for that could use no index.
Turn off Rushmore and execute it again. Surprise ?
How often do you use Rushmore optimizable expressions without optimizing by yourself ?
With Rushmore I wonder if you would have most current rec set.
One of the first tips in FoxPro ;
If you have an index tag on f1+f2 but not on f1, in search use f1+f2 = m.f1 instead of f1=m.f1.
Was Rushmore born later ?

In fact I don't have documentation about what really Rushmore is and how it works.
FoxPro docs don't say much about it.

>>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).
I would bet in NO CASE. But again you say the same thing "Rushmore optimized". If it could be optimized you won't need more speed.
>
>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.

Of course physical situations impact on performance,
but I wouldn't sort my tables periodically as Dev.Guide says.
I think FoxPro programmers generally face *unusual*.
But in short I agree using *SCAN FOR* is good for it doesn't need much expertise.

Cetin