Here's the questions I start asking in situations like this

What's different between where it's working and where it's not?
All of these are coming off the same server/data location?

The answers to the above two will lead to more questions, usually.

Though I am curious why it's doing a report with a relation rather than running a query to pull the data into one file and reporting off that file




>>>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.