I also just found out about this a month or two ago. Well, actually some of the developers on our project who are new to FoxPro had coded a SCAN that selected another table inside the loop. During a code review, I told them that they needed to re-select the SCAN table at the end of the loop. They said that it worked without re-selecting the table, and guess what -- it did. I seem to remember in 2.6 that I had to re-select the SCAN table at the end of the loop, or else it would start SCANning through the other table, but it doesn't appear that way in VFP. I haven't seen any documentation one way or the other, so I've been debating about whether I need to re-select the table if another has been selected. It looks like you don't need it, but for my own sanity, I may continue doing so.

>Hi John,
>If it makes you feel any better, I found this out only a month ago. FPW did not do this and if I changed the alias inside the loop, I'd add the select alias at the end of the loop without thinking. I never thought to test it any other way.
>
>>Hey UT folks -
>>Sometimes I feel like a total idiot savant with VFP. Some features I know as well as the people who designed them, then I hit something like this .. which is probably something everyone but me knew about.
>>
>>Here's the feature I didn't know about, but came across by accident:
>>
>>Did you know that when you issue a SCAN/ENDSCAN VFP automatically flips a SELECT back to the correct file when hitting the ENDSCAN without you having to explicitly doing so?
>>
>>Here's an example program:
>>
>>SELECT j1
>>
>>SCAN
>> SELECT j2
>> LOCATE FOR ord = j1->rec
>> IF NOT FOUND()
>> APPEND BLANK
>> REPLACE ord with j1->rec
>> ENDIF
>>ENDSCAN
>>
>>Now I would have expected this to bomb, because I didn't issue a 'SELECT j1' after the REPLACE and there's no 'ord' field on the 'j2' file. But when the program hits the ENDSCAN, it reverts to 'j1' automatically!
>>
>>Please someone tell me this is new and not been around since VFP 3 or FoxPro 1.0. Yeesh!