>>>In a FoxPro 2.6 application, I need to replace fields by using a relation. I thought it should work, but it doesn't.
>>>
>>>

>>>USE Navigation
>>>SET FILTER TO MyField = 1
>>>
>>>USE Dataentry
>>>SET FILTER TO MyField = 100
>>>SET ORDER TO EmpNumber
>>>
>>>SELECT Navigation
>>>SET RELATION TO EmpNumber INTO Dataentry
>>>REPLACE ALL DataEntry.OtherField WITH 1
>>>

>>>
>>>Strange thing, it does not have any effect. Maybe I'm missing something?
>>
>>I saw that you solved the problem. Just wanted to remind you that REPLACE is evaluated in the current workarea and if that table is at EOF(), nothing is changed.
>>
>>Tamar
>
>Hi Tamar
>
>Does that apply with a REPLACE ALL as in this case?

Good question. It's actually quite ugly. You get as many replacements as there are records in the current work area. Here's what we said in HackFox:

"The fields do not all have to be in the same table. However, there's a gotcha here. The Scope, FOR and WHILE clauses are applied to the controlling table (usually the current work area). If you reach EOF() in that table, no further replacements take place in any table. Despite much yelling by many Xbase programmers over the years, this really isn't a bug. It's supposed to work this way and it's as good a choice as any other behavior in this situation.

Here's the deal. REPLACE lets you change fields of multiple records in multiple tables at once. Suppose you've written a REPLACE that moves data into records from three different tables at once. Suppose further that the REPLACE has a scope clause of NEXT 5. What if you reach the end of one of those tables before you've hit five records? For simplicity's sake, the rule has always been that it's the current work area that counts. As long as you're not at EOF() in the current work area, the REPLACE continues (although some data may land in the bit bucket). As soon as you hit EOF() in the current work area, the REPLACE ends. No questions asked."

Bottom line is that one should NEVER do REPLACE in a work area other than the current work area. In recent versions, adding IN to REPLACE solves the problem. In FP2.x, every REPLACE should be preceded by the appropriate SELECT command.

Tamar