The parent pointer is continuously changing within it's scan loop.
As I mentioned, I did some debugging. I suspended the process at an identified point where the child record was not in sync with the parent.
At that point I was able to confirm that the relationship was set correctly and that the appropriate index tag was active. Yet the child record was not in sync with the parent.
Run the same routine using VFP9 and there is no issue. All tables have the same code page.
Kludging it with seek() to the child table forces the routine to work.... and is my fix for the moment.

>>>>>Hi,
>>>>>
>>>>>I've recently encountered a baffling issue, and would appreciate it if anyone has a explanation.
>>>>>First, I'm using VFP9 in my development environment, but the production environment uses VFP7.
>>>>>The start program is an exe compiled with VFP7 and the rest of the sub programs are FXPs.
>>>>>
>>>>>One new report uses a table related by Employee ID to another table.
>>>>>For some strange reason, under VFP7 the relationship is not correctly moving the pointer for the second table as in:
>>>>>
>>>>>USE TableOne ORDER empid shared
>>>>>USE TableTwo ORDER empid shared in 0
>>>>>SET RELATION TO empid INTO TableTwo
>>>>>
>>>>>TableOne empid is one value, tableTwo empid is not the same under VFP7, but works fine under VFP9.
>>>>>This is causing the report to yield 100's or records under VFP7 and 10's of thousands of records (correctly) under VFP9.
>>>>>
>>>>>I reindexed the tables - no luck.
>>>>>I did notice that the problem was was with 2 sites, but not the third where it worked just fine (all under VFP7)
>>>>>
>>>>>I have kludged it to work with a:
>>>>>=seek(TableOne.empid,'TableTwo','empid')
>>>>>
>>>>>...but this is fundamental and I'd like to know what I've done wrong...
>>>>>
>>>>>TIA
>>>>Hi Ashley
>>>>
>>>>IIRC you have to move the record pointer after SET RELATION, as one has to for SET FILTER. That may be why the seek is fixing it in VFP7?
>>>
>>>No sure what you mean.
>>>In this case the relationship has been set between the controlling table and the child table, and the child table has the correct index active and the relationship is one to one.
>>>As the controlling table goes through a scan loop, the child table pointer should move to the corresponding emp id record.
>>>This is normal behavior since FoxPro DOS days...
>>>Under VFP7 it is not. Under Vfp9, it is.
>>>And this is happening with some departments and not with others.
>>
>>My gut tells me every time I used SET RELATION, I had to LOCATE in the parent to to move the record pointers in the children. A SCAN should be doing the same.
>
>I think that is correct. I haven't done such a thing in many years but I think you had to move the parent pointer before the child records sync'd up.
>
>I think SCAN by default kicks to TOP so it effectively moves the pointer. SCAN REST might not. Been too long since I did VFP relations.