>I quote from the VFP help file on the REPLACE command:
>

Note   If the IN clause is omitted, no replacement occurs
>if the record pointer is at the end of the file in the current
>work area and you specify a field in another work area.

>
>Huh? .... it's true...just try it...

>
>select table1
>replace table1.c with 'A'            &&init value
>select table2                        &&new workarea
>locate for .F.                       &&go eof
>replace table1.c with 'B'            &&try it
>?table1.c                            &&yeilds 'A'
>go top                               &&go bof of table 2
>replace table1.c with 'C'            &&try it
>?table1.c                            &&yeilds 'C'
>locate for .F.                       &&eof table 2 again
>replace table1.c with 'D' IN table1  &&try it with the IN clause
>?table1.c                            &&yeilds 'D'

>Would anyone like to explain the origin of this FODU ('feature of dubious utility') to me?
>
>Let me guess - if you fall off the end of a parent table, VFP is preventing you from altering the related child ... well fine. Then only apply the rule when the two tables are related (or better yet ... just write into the void).
>
>I got nailed by this obscure feature and I feel very lucky to have discovered the fine print at the bottom of the REPLACE help before spending hours trying to figure out why the replace wasn't happening.

This "feature" has been around as long as xBASE. My understanding is it has never been fixed because some programs might actually rely on it working this way.

FWIW the IN clause makes managing this easier than it used to be.