Actually, nothing is ever that simple. LOCATE is faster than GO TOP when a filter or set deleted is in effect. That's because LOCATE/CONTINUE is Rushmore Optimized, but GO TOP/SKIP is not. GO TOP is faster when there is no filter, no deleted records or no indexes.

There would have to be a large number of filtered-out or deleted records between the TOP record and the first filtered-in non-deleted record for you to notice. Notice I said TOP record, not record 1. If there is a SET ORDER in effect, the TOP record may not be record 1.

If you have

select * from someplace where somecondition into cursor somecursor nofilter

GO TOP would beat LOCATE, because there are no indexes on somecursor for Rushmore to use.

*If* you have already used LOCATE, then you might use CONTINUE instead of SKIP, but, there'd have to be lots of filtered-out or deleted() records between the current record and the next filtered-in, non-deleted record.

>Now that last bit I didn't know! You learn something new every day. :-). This ability has been going since at least VFP 3 but it wasn't documented then. I was surprised when I saw it in VFP 7.

This has been true since FoxPro 2.0 for DOS at least. I had occasion to test it in the last 6 months of 2003 while working in that environment.

LOCAL HARD DRIVE - NO LAN.
Test result 1:
Envrionment: 100,000 records. First 50,000 are deleted. No index on DELETED(). SET DELETED ON.
5000 GO TOP = 159 seconds
5000 LOCATE = 140 seconds

Test result 2:
Envrionment: 100,000 records. First 50,000 are deleted. Index on DELETED(). SET DELETED ON
5,000 GO TOP = 151 seconds
5,000 LOCATE = 9 seconds

Test result 3:
Envrionment: 100,000 records. First record recalled. Next 49,999 are deleted. No index on DELETED(). SET DELETED ON
increased to 50,000 LOCATES = 0.071 seconds
increased to 50,000 GO TOP = 0.340 seconds

LAN

Test result 1:
Envrionment: 100,000 records. First 50,000 are deleted. No index on DELETED(). SET DELETED ON.
5000 GO TOP = 160 seconds
5000 LOCATE = 130 seconds

Test result 2:
Envrionment: 100,000 records. First 50,000 are deleted. Index on DELETED(). SET DELETED ON
5,000 GO TOP = 149 seconds
5,000 LOCATE = 8 seconds

Test result 3:
Envrionment: 100,000 records. First record recalled. Next 49,999 are deleted. No index on DELETED(). SET DELETED ON
increased to 50,000 GO TOP = 0.100 seconds
increased to 50,000 LOCATES = 0.330 seconds

For me, this is all totally unrealistic. I use SQL Pass Thru to get local or remote data. The tables will be optimized to aid in those queries. The resulting cursors are not going to have DELETED() tags. There are not going to be that many deleted records, and they would be filtered out by queries. There may be tags for dynamically reordering these cursors in a grid. These would not be useful for filtering, and the cursors are unlikely to be filtered.

Test result 3 LAN or local would be my usual environment. Therefore GO TOP would be my normal choice.



>
>Terry
>>
>
>
>>Handy to know... doesn't mention anything about that in my help (vfp6). It appears you can then use CONTINUE in place of SKIP if you wanted to.
>>
>>You learn something new every day.
>>
>>Ben