>>>>>>Marcia, I am surprised that you can do this mistake. :-)
>>>>>>Set Top can be extremely slooooooow on a big table. Instead you should use Locate.
>>>>>>
>>>>>>As you may remember, Andy did several sessions on optimizing VFP code and this is what he wrote in his 2005 session:
>>>>>>
>>>>>>Locate vs Go Top
>>>>>>One of the conventions that has passed into FoxPro mythology is that a LOCATE command is faster than using GO TOP, and that by reversing the index order on a table and using LOCATE performance is better than just using the GO BOTTOM command. However, as the following table shows, this is only true when you are using Filters and is more to do with the fact that the LOCATE command is optimizable (as shown above) than anything else. In VFP 7.0 the difference between the two commands is smaller than in previous versions anyway. Of course, GO TOP and GO BOTTOM retain one huge advantage over LOCATE because they can take an IN alias clause, thereby obviating the need to change work areas.
>>>>>>
>>>>>>

>>>>>>Methodology                          GO TOP   LOCATE      GO BOTTOM	INVERT INDEX  AND  LOCATE
>>>>>>No Filter	                                0.030	0.060	0.300	0.070
>>>>>>Filter Not Optimizable	        0.010	0.020	0.100	0.071
>>>>>>Filter Partially Optimizable	0.010	< 0.001	0.952	0.140
>>>>>>Filter Fully Optimizable	        0.010	< 0.001	1.021	0.140
>>>>>>

>>>>>
>>>>>Since a filter is in deed used in this case, Locate would be faster if the table has an index tag on Empty().
>>>>
>>>>This is only applicable if there are a lot of delete records. If there are none, GO TOP and GO BOTTOM are fast in any case because they do not have the overhead of rushmore.
>>>
>>>Deleted records or not, my conclusion is correct. The important point here is Set Filter, and whether the filter expression matches an index tag or not. If you want to argue, that's fine, but I don't want to participate.
>>
>>Hi Tore
>>
>>I wrote the original article on this in 1995 when I was working with multi-million record tables and filters. Walter's reply to you here is right. It's not only that there is a filter expression matching index. It also requires lots of records at the top of the current index order that do not match the filter. In that case LOCATE will beat GO TOP by a much greater margin. If you have SET DELETED ON, which is the equivalent of a filter and there are many deleted records LOCATE will win again. A trick that I introduced in that article is INDEX ON 'A' tag xATAG. The records are then in physical sequence. You can then issue a SET ORDER TO xATAG DESCENDING followed by a LOCATE to GO BOTTOM.
>>
>>GO TOP/BOTTOM works faster on small unfiltered cursors. Since I use cursors a lot, I've been using GO TOP/BOTTOM much more in the last several years.
>
>1995 means before VFP9. VFP9 added binary index tags. I forgot to mention it here, which makes us both be right, depending on what kind of index tag you have. With a binary index on Empty(), I am right. With a normal index, you are right. I never use normal index tags for logical expressions, only binary index tags. I'm sorry that I forgot to mention that earlier.

Knowing that empty is not optimizable unless a custom index tag is added - I would opt for using any hopefully existing tag on the field itself, as I replied to the OP. :)