>>>I remember reading several years ago that Scan...EndScan loops should not be nested because some records do not get processed properly. Is this still the case in VFP7?
>>>
>>>Thanks very much.
>>>Stan
>>
>>You only need to be careful if you have a FOR condition which is optimisable AND you are changing key values within the loop. No problem with nesting, except if you are scanning the same table, in which case store the pointer.
>
>Dave, the slight problem here turned up because the innner scan would land on the first record which was not satisfying the condition, and the outer scan would need to operate on the last record which was used in the inner scan, therefore I would be doing it this way, adding the while condition and saving the recno() as the last thing in the inner scan. Of course, this example serves a different purpose: your way, each scan is performed for each record; my way, the inner scan is performed on each record, and the outer sees the first record of each group before the inner scan comes up, and then the last record of the group when it exits.
>
>>SELECT TableA
>>SCAN
>> do something
>> SCAN while something
>> do somethingelse
>> nRec= RECNO()
>> ENDSCAN && TableA
>> GO m.nRec
>>ENDSCAN && TableA

Yep, and as J Booth said, as long as you understand what is happening to the record pointer, there is no problem. Speaking of strange record pointer behaviour did you see the post on where
LOCATE RECORD xxx
ignores the current filter condition. Sort of surprising. Again it not something I'd ever use but the guy wanted a way of quickly getting to the next record with a filter set. GO RECORD xxx certainly ignores the filter (and rightly so) but LOCATE in every other instance obeys the filter setting.
CU