George,

>>LOCATE respects the SET FILTER clause. It is the filter that get's optimized

>Yeah, that's what JimB pointed out. However, as I mentioned elsewheres, I can find no circumstance that would allow its use in place of GO TOP.

For some reasons, (obviously beyond my knowledge) GO TOP doesn't invoke rushmore on the SET FILTER clause. Therefore if you've got a large table and set a filter in which the first record which matches it is about the 100000th record foxpro sequently scan the whole table until the 100000th record when using GO TOP. When using LOCATE rushmore gets to work and finds the 100000th record via the indexes in no-time.

So when using filters (filters which filter out a significant contineuous number of records at the beginning of the table), LOCATE is significantly faster than GO TOP.

In the time I rewrote clipper apps I many times did find constructions like these.

SET ORDER TO TAG ID
SET FILTER TO somefilterClause
GO TOP
DO WHILE !EOF()
    ... do something else
    REPLACE ID WITH someothernumber
    GO TOP
ENDDO

This was a real performance killer because the go top cause the application to sequently search the whole table again until it reaches a record which met the filter condition. In clipper there initially was no rushmore (until the six driver) so there was no alternative. In foxpro we could boost performance by simply replacing the GO TOP with LOCATE and make sure the filter is optimizable. Of course to make use off al the benefits of VFP we would rewrite this routine ;-)

Walter,