A good insurance policy would be to include the "IN" clause.
REPLACE target.field WITH source.field IN target

>Thank you Marcia for that in depth explanation.
>
>>Hi Denis.
>>
>>replace MyTable.MyField with lcWhatever
>>
>>did'nt work but
>>
>>I see that the others have already told you that the reason it didn't work is because the currently selected work area is at EOF(). Just in case you'd like a little more in depth explanation, here is a exerpt from a session I gave last year called "It Seemed Like a Good Idea at the Time:
>>
>>One of the most useful techniques in Visual FoxPro is the ability to update a table in a work area which is not currently selected. This allows us to write code like this:
>>
>>

>>SELECT source
>>IF target.field # <somevalue>
>>	REPLACE target.field WITH source.field
>>ENDIF
>>

>>
>>But have you ever had a situation when it just didn?t seem to work? Or when it worked in some situations but not in others? You open up the Debugger and walk through the process. You can see that the field you're copying from has the right value and that the REPLACE command gets executed, but the target field doesn't change. What gives?
>>The answer is that you've run into the dreaded "REPLACE at EOF()" problem. REPLACE, like many of the original xBase commands, is a ?scoped? command. Scope is a set of four choices (ALL, REST, NEXT n, RECORD n) that determines what records are affected by a command. Each scoped command has a default scope. For non-destructive commands (like LIST, DISPLAY and BROWSE), the default is ALL. For destructive commands (like DELETE and REPLACE), the default is NEXT 1 to keep you from blowing away your data by accident.
>>
>>What does this have to do with the update that's failing? You're using REPLACE and you only want to change one record. What's scope got to do with it? Scope applies to the current work area, which may not be the target of the REPLACE (in fact, surely isn't if you're having this problem). If the record pointer in the current work area is at EOF (end-of-file), no REPLACE occurs, because there's no field to be replaced. For example:
>>
>>

>>SELECT TableB
>>REPLACE TableA.Field1 WITH Field2
>>

>>
>>fails if TableB is at end-of-file.
>>
>>When folks encounter this behavior for the first time, they usually holler "Bug! I found a bug!" but they're wrong. It's designed to work this way and it makes sense. If REPLACE could only update a single record and field at a time, this behavior wouldn't be necessary. But you can write a REPLACE like this:
>>
>>

>>REPLACE TableA.Field1 WITH Value1, ;
>>        TableB.Field2 WITH Value2, ;
>>        TableC.Field3 WITH Value3
>>

>>
>>Whose scope should apply in this case? The rule is always the same - the current work area. If you didn't have that rule, what would you do if one of the destination tables was at end-of-file - replace some and not the others? The rule means you don't do any of them, which feels right.