ManiB,
Code:
SELECT _cursor
LOCATE && faster than Go top
SKIP
SCAN REST
? _cursor.id
ENDSCAN
That is correct, and will skip the first record with whatever index sort order is set for ordering of the data. LOCATE also will take that ordering into account. And both LOCATE and SKIP will also take into account any FILTER set. In such cases with index and filter, as Mike Lewis already said the FOR scope will have disadvantages, And Mike Yearwood also is correct that FOR RECNO()>1 would only be optimized when an index on RECNO() exists, which you'd usually not have. The FOR RECNO()>1 I gave was mainly pointing out that SCAN supports more scopes then the full scope or SCAN REST, there is FOR, NEXT and WHILE, so you can also only SCAN the Top 10 records with LOCATE an SCAN NEXT 10.
In very short, once more: Pay attention to record scopes existing, besides FOR and ALL, there's NEXT and WHILE and people don't know about these options very often. So you have very many options to control which records are processed with these scope clauses instead of needing IF statements within the loop body and then LOOP to skip a go back to SCAN instead of continuing in the loop body code. But that in itself is also worth knowing, just like you can EXIT from a scan loop like you can from a FOR or DO WHILE loop, too.
All this is just basic knowledge about record scopes (not variable life scopes) and loops in general and you usually learn this as one family of knowledge that belongs to be known together.
One further thing that belongs to the topic of filtering is that you can also filter to records with the same index key using SET ORDER together with SET KEY. And that can be combined with SET FILTER or a FOR clause, too. It binds you to usage of the index that will also determine the order overall, but then SET KEY will usually be used for a single key, which makes sense to loop through all records with the same foreign key. It makes less sense with a primary key, as that's just one record then, which requires no loop.
And to finish this SET KEY ca be used with a RANGE option, too.
All in all, you have so many options, that you will only need IF logic in the loop body for rare complicated cases. You can combine SCAN with its record scope clauses with a SET ORDER, SET FILTER and SET KEY [RANGE]. And then you can also define Relations from one workarea to others and have SET SKIP, which means you can loop through a set of workareas with related data even without nesting SCAN loops.
All this together and only ALL this together enfolds how xBase can do things for which you would otherwise need SQL. And still SQL can be better in other cases. Usually when you mainly just want the resultset and not process the records that belong to the result set within the loop body. Well, and that processing within the loop also has to be done with caution, as Mike Lewis already pointed out, since manipulating data while you scan through it with scopes and order and filters, can change your current position within the set of records you loop through.
I remember people saying they still prefer the old DO WHILE !EOF() with SKIP because that gives them more or full control, and you can then conditionally not SKIP or SKIP 2 or whatever. Well, you are still allowed to SKIP in a SCAN loop, too, you just need to keep in mind a SKIP 1 is automatic from the ENDSCAN, so to Skip 1 row from processing you SKIP 1 and not SKIP 2. But it also looks more normal to me to SKIP 1 record, for example. So all inn all, that should tell you why everyone should be a big fan of the SCAN loop over the DO WHILE loop. You can simply express your plan of scanning with all the scope clauses that would otherwise need an IF, or even several IFs and conditional SKIPs and what not, that's you can all very precisely an elegantly specify in the record scopes clauses of a SCAN..ENDSCAN loop.
Chriss
