Thanks Vlad!
I noticed the restrictions when I read the fine print in REPLACE. I've experienced about a year back when I noticed a SCAN loop was acting funny!

Rock `n Roll:)
Terry

>Hi!
>
>In addition:
>you can use
>
>replace MyDBF.MyField with lcSomeValue in MyDBF
>
>Above does not require to select any workarea explicitly just to avoid problem with eof() in current workarea.
>
>HTH.
>
>>Thanks for the point Malcolm. I believe that was it - AND - am relieved.
>>Again - Thanx
>>Best Regards
>>Terry
>>
>>
>>>Terry,
>>>
>>>Look for an Eof() condition in one of your tables. If you read the fine print in the replace command's help topic you will see more info on this weird - but 'by design' behavior.
>>>
>>>Good luck!
>>>Malcolm
>>>
>>>
>>>>First time for this:
>>>>Changes to a combo setting push a message to user offering to replace the contents of a "Master" DBF field.
>>>>
>>>>When the code instructs:
>>>>replace MyDBF.MyField with lcSomeValue - it does not take.
>>>>
>>>>However, when code instructs:
>>>>select MyDBF
>>>>replace MyField with lcSomeValue - it takes.
>>>>
>>>>It's one little interactive procedure. A form deactivate fires a "custom" data session object in service of a MESSAGEBOX just before the REPLACE. Maybe some foobar character codes hidden in the PRG file. Just weeeeerd.
>>>>
>>>>The "->" field pointer has same non-result.