No argument there. It's just that going to the end of the table is REAL fast if it is properly optimized. SKIP -1, which is not optimized, may still be faster because it probably has less records to scan through.
Like I said, I have not benchmarked this but it seems to me like that is the way it should work out most of the time.
Menachem
No, this is not true.
GO BOTTOM is:
FSEEK(tableHandle,fn(RECCOUNT()))
SKIP -1 scan loop
and fseek is faster respect to a index b-tree search.
Proof:
SET ESCAPE ON
CLEAR
CREATE CURSOR myWA ( fone I DEFAULT RECCOUNT())
FOR k=1 TO 100000
APPEND BLANK
ENDFOR
N=10
R=1
?
? "WORST CASE: ONLY FIRST RECORD NOT FILTERED"
? REPLICATE("-",100)
? "BOTTOM" AT 30,"LOCATE" AT 60
? REPLICATE("-",100)
SET FILTER TO FONE=0
T1=SECONDS()
FOR K=1 TO m.n
GO BOTTOM
ENDFOR
? 'FILTER',SECONDS()-T1 AT 20,FONE
T1=SECONDS()
FOR K=1 TO m.n
LOCATE FOR .F.
SKIP -1
ENDFOR
?? SECONDS()-T1,FONE
INDEX ON fone TAG mtag
T1=SECONDS()
FOR K=1 TO m.n
GO BOTTOM
ENDFOR
? 'INDEX ACTIVE',SECONDS()-T1 AT 20,FONE
T1=SECONDS()
FOR K=1 TO m.n
LOCATE FOR .F.
SKIP -1
ENDFOR
?? SECONDS()-T1,FONE
SET ORDER TO
T1=SECONDS()
FOR K=1 TO m.n*m.r
GO BOTTOM
ENDFOR
? 'INDEX NO ACTIVE',SECONDS()-T1 AT 20,FONE
T1=SECONDS()
FOR K=1 TO m.n*m.r
LOCATE FOR .F.
SKIP -1
ENDFOR
?? SECONDS()-T1,FONE
DELETE TAG ALL
R=1000
SET FILTER TO FONE=99999
?
? "BEST CASE: LAST RECORD NOT FILTERED"
? REPLICATE("-",100)
? "BOTTOM" AT 30,"LOCATE" AT 60
? REPLICATE("-",100)
T1=SECONDS()
FOR K=1 TO m.n
GO BOTTOM
ENDFOR
? 'FILTER',SECONDS()-T1 AT 20,FONE
T1=SECONDS()
FOR K=1 TO m.n
LOCATE FOR .F.
SKIP -1
ENDFOR
?? SECONDS()-T1,FONE
INDEX ON fone TAG mtag
T1=SECONDS()
FOR K=1 TO m.n
GO BOTTOM
ENDFOR
? 'INDEX ACTIVE',SECONDS()-T1 AT 20,FONE
T1=SECONDS()
FOR K=1 TO m.n
LOCATE FOR .F.
SKIP -1
ENDFOR
?? SECONDS()-T1,FONE
SET ORDER TO
T1=SECONDS()
FOR K=1 TO m.n*m.r
GO BOTTOM
ENDFOR
? 'INDEX NO ACTIVE',SECONDS()-T1 AT 20,FONE
T1=SECONDS()
FOR K=1 TO m.n*m.r
LOCATE FOR .F.
SKIP -1
ENDFOR
?? SECONDS()-T1,FONELOCATE + SKIP is slower, always.
Fabio
