>>>>>replace (lcFiledName) with lcValue in (lcAlias) && this is much better and safer syntax
>>>>
>>>>Why is it safer -- seems to be only a matter in choice of syntax? Both accomplish the same task exactly every time, nothing more nothing less...
>>>
>>>You should make it a practice to use the IN clause every time in every command that accepts it. It prevents accidentally doing something in a work area other than the one you meant.
>>>
>>>REPLACE x WITH y IN z
>>>
>>>is better than
>>>
>>>REPLACE z.x WITH y
>>
>>To me both are equivalent in protection. The first has the alias after the IN clause; the second has the alias as part of the field name. Both can only save to the named alias and field -- no chance of wrong table. You cannot have two tables open with the same alias in a given data session. You cannot open the same table twice with the AGAIN clause without using a different alias. So the alias gives the assurance that the correct field is replaced in the correct table.
>>
>>The only benefit of the IN clause is if another workarea is current with the table at EOF, then the REPLACE command will not fail (providing that the table record pointer is also not at EOF). So I don't see that any "accident" can happen with either statement above. If the alias was not referenced in the second (or the first for that matter) then an "accident" could happen... To prevent failure of the REPLACE command, I long ago (back in FP 1.0 days) starting the habit of ensuring the current table is the one specified by the ALIAS by using a SELECT {tablealias} command before issuing a series of REPLACE commands. There is some overhead in this, but it is quite small...
>
>No, it's not the same. There are all kinds of things which can change the workarea other than in-line code (setting focus to a grid, a timer, an OKL, ...). The only way you can be sure you're in the right workarea is by using the IN clause.
>
>Tamar

_VFP.AutoYield = .F. and nothing will trouble exeqution sequnece. ::)

Agnes