I know about this, I wrote the post <g>. It is not significant as there is no grid involved.

You should be able to get more user selection criteria to reduce the number of records returned. Does anyone ever need to see 200,000 records? Do they really just look at the first page or two?

>Here a previous post :
>
>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
>
>The timing for the first loop is 0.084 seconds and the second is 5.288 seconds. The second loop is significantly slower.