I have a solution running on FM11 that uses a robot client to run several schedule scripts 24/7. I've run this for years and have used error capture to prevent robot client from pausing on benign errors, which has worked fine in many different scenarios. I recently set up a new script that this is still pausing on robot with error message regarding record lock and prompting for client to choose to revert their changes or overwrite changes another user has made. (If actual staff had made a change but neglected to exit or commit record before the robot client picked up the record change to force another step).
The nature of the robot script is that when a specific set of fields in a record are changed, it marks a flag field. The robot script finds the flagged / changed records and executes a step to make changes to related SQL record using an ESS relationship. It then also clears the flag in the native FM record.
Part of this was a strategic error on my part. I originally set up the robot schedule to run frequently so often it would be trying to jump and do the ESS update while staff was still in the record. However, I moved this routine back to a once-nightly script during off-hours and it is still getting caught with the record lock error.
I also had attempted to resolve by adding a check for RecordOpenState, to skip the update if OpenState did not equal 0, i.e. record was closed or committed.
I can't figure out what is unique about this specific record update process, that throws the error message in a way I have not seen elsewhere. Happy to post script if needed but appreciate any insight on this.