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

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

As far as I remember, this was about SCAN FOR vs. SEEK + SCAN WHILE. If the number of scanned records is not very small compared to the total number of records, SCAN FOR is much faster then SEEK + SCAN WHILE. Of course, with Rushmore optimizable expressions.

>Rushmore optimization ? This would be long subject. just think how often you use it.

I use it as often as I can. Why? I shouldn't use it?

>I think you also write code already optimized.

Already optimized by who?

>Try setting so many tags and execute a ;
>SCAN...ENDSCAN with for that could use no index.

If it can use no index, then is not Rushmore optimizable. So, it's not in the case I said.

>How often do you use Rushmore optimizable expressions without optimizing by yourself ?

You mean? Sorry, but I don't understand this phrase.

>With Rushmore I wonder if you would have most current rec set.

Yes, I know about this issue. It's true that sometimes you must turn off the optimization.

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

This is true for SET EXACT OFF.

>Was Rushmore born later ?

I don't get this either.

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

No, but it says what to do in order to use 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).

My mistake here: Not in the child table (there's no child table :)), but in the scanned table.

>I would bet in NO CASE. But again you say the same thing "Rushmore optimized".

You would lose your bet. Believe me! And if you don't, take a table with a few tens of thousands records and apply both methods for a condition that selects 10-20% of the table.

Of course I say "Rushmore optimizable/optimized". This is the only thing that makes FoxPro soooo fast. If you don't use it, you don't use the FoxPro's power.

>If it could be optimized you won't need more speed.

Again, I don't understand this.

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

Much expertise?!? Does it require less knowledge than SEEK + SCAN WHILE?

Actually, it requires a little more. Because it requires to know which expressions are optimizable. SEEK + SCAN WHILE doesn't.

Vlad