>>>>>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.
>
>Nope - relation kicked in immediately
>You probably have that recollection because most of the time you're setting a relation and then either doing a seek in the first table or a 'go top' for the beginning of a scan

No need for a go top/locate before a scan or scan for.