Each time a user or a script starts to modify a record, it is "opened" for editing and the record is locked against edits by other users and scripts. You can even lock a record against editing by the same user that has it open for editing should they put the cursor into a field in one window of a record and then attempt to modify data for the same record in a different window.
Replace Field Contents is a useful tool for updating large groups of records in a single batch operation, but is best used in situations and on records where it is impossible for a different user or script to lock one or more of the records. If Replace Field Contents attempts to modify a locked record, it skips to the next record and an error is reported that one or more records could not be modified. Thus, you know that one or more records did not get modified, but not which ones.
Instead of replace field contents, however, you can use a looping script that modifies each record one at a time. You can use the Open Record/Request step to open and lock the record for editing. By Using Set error capture and Get ( LastError ), you can use this step to check for an edit lock and open it (and thus lock it) if it is not.
So...let's say worst case a user is already editing a text field called "notes" and is unfortunately writing a book-long summary of his or her call with their customer, and it takes them 3 minutes to complete. They are in edit mode for 3 minutes and the record is locked for 3 minutes, right?
If so, and my script can detect which records were locked / failed to update, what do I do now???
You are correct.
I'd work very hard with my database design so that such a scenario is impossible or highly unlikely.
Once your script has attempted and failed to update a locked record you have several options:
1) Report back to the user who performed the script a found set of unmodified records. The user then decides whether to try again, contact the other user and get them to release the records. (They don't have to be writing the great american novel, they might just leave the cursor in the field and go home for the day...
2) Go into a loop that tries repeatedly to update the record or records. If you select this option, build in a counter and revert to option 1 after a certain number of attempts still fail to modify the record.
3) Put a List of serial numbers of locked records, plus any needed details detailing the update into a new record in a utility table. Set a flag so that a housekeeping script set to run a 1am in the morning completes the update.
Yikes. That's enough to scare me away from this whole design. I didn't consider having to protect against this scenario.
I hate to say it, but I think I'm way in over my head on this....