>Here sample code posted here, where you can see the differences between INDEX and SET FILTER (5 sec) and SET FILTER alone (0.1 sec) :
>
>Its my understanding that Rushmore Optimization cannot work as effectively with SET ORDER TO as it can without it. The set order will far outweigh any benefit gained by the seek.
>
>I built a table with this code...
>
>CREATE TABLE SPEED.DBF FREE ;
>(Spd_ID I, ;
>Spd_Char C(10), ;
>Spd_Date D, ;
>Spd_DT T)
>LOCAL lnI, lnX, Spd_ID, Spd_Char, Spd_Date, Spd_DateTime
>FOR lnI = 1 TO 1000000
>SPD_ID = m.lnI
>SPD_CHAR = STR(m.lnI)
>*This will give me a set of records
>*with the same date / date time.
>lnX = m.lnI/100
>SPD_DATE = {^2000-01-01}+m.lnX
>SPD_DT = {^2000-01-01 00:00:00}+m.lnX
>INSERT INTO SPEED FROM MEMVAR
>IF MOD(m.lnI,1000) = 0
>WAIT WINDOW STR(m.lnI) NOWAIT
>ENDIF
>ENDFOR
>INDEX ON SPD_ID TAG SPD_ID
>INDEX ON SPD_CHAR TAG SPD_CHAR
>INDEX ON SPD_DATE TAG SPD_DATE
>INDEX ON SPD_DT TAG SPD_DT
>WAIT CLEAR
>
>Then I timed bits of code similar to the ones you posted. I ran this on a local hard drive with 256 megs of RAM and a P3 650.
>
>LOCAL lnA,lnI, Spd_Date
>USE SPEED
>Spd_Date = {^2027-05-19}
>lnA=SECONDS()
>FOR lnI = 1 TO 10
>SELECT SPEED
>SET FILTER TO Spd_Date=m.Spd_Date
>SCAN
>?SPD_ID
>ENDSCAN
>ENDFOR
>?SECONDS()-lnA
>
>lnA=SECONDS()
>FOR lnI = 1 TO 10
>SELECT SPEED
>SET ORDER TO TAG Spd_Date
>SEEK(m.Spd_Date)
>SET FILTER TO Spd_Date=m.Spd_Date
>SCAN
>?SPD_ID
>ENDSCAN
>ENDFOR
>?SECONDS()-lnA

In a case like this, I personally prefer a third approach: no filter, but a SEEK, followed by SCAN WHILE . That should be quite fast.

Also, my original concern was about using a filtered table within a grid.

Hilmar.

Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)