1 of 1 people found this helpful
It can cause a problem, yes.
The replace will not be able to modify the record that another user has the 'lock' on and will not tell you which record that was. If you have set error capture: on, you can use Get(LastError) to see if it was successful, otherwise you should see a dialog informing you of such.
So you will need to take that into consideration with deciding how to proceed. You could for instance, loop through the records and make the change, tracking along the way if it was a success or locked and revert the process on failure, or commit on success.
In some cases, when get ( LastError ) detects the record lock error after doing a Replace Field Contents, your script could perform a find to find the records that were not modified and list them for you so that you can deal with the issue.
Steve's suggestion of using a loop with Set Field is one I use often, especially when updating multiple fields. For me, not only does it simplify error capturing, but is also somewhat easier to understand and edit. I seem to remember that the last record in a Replace wasn't "committed" until using Go To Field, or Commit Records.
Replace field contents is not a transactional process and can be impacted by record lock.
Use with caution.
For a safer handling, I would look up toddgeist's site and review the articles and videos on Transactions.
I rarely use Replace Field Contents, it can be dangerous for data integrity. There are ways to handle it...or alternatives to processing the records.
thanks everyone, all very helpful