Смотря, что именно ты хочешь получить. Сформулируй словами.

Дело в том, что IsRLocked() возвращает .T. для записей, которые ты сам и заблокировал. Т.е. она ничего не может сказать о блокироваках сделанных другими пользователями.

Функция RLOCK() или LOCK() блокирует записи. Т.е. если запись не удалось заблокировать, значит она заблокирована другим пользователем. НО! весь вопрос в какой именно рабочей области? Т.е. в какой таблице?

Дело в том, что команда Select-SQL может создавать временные таблицы на момент своего выполнения. И вполне вероятно, что она будет блокировать записи не в твоей исходной таблице, а в своей временной. Т.е. результат будет далек от ожидаемого.

Еще раз. Сформулируй словами, что именно ты хочешь получить. Именно словами. Без функций и команд.

Проверка факта блокировки ДО попытки заблокировать данные не имеет смысла.

Предположим, тебе удастся получить список записей заблокированных (или нет) другим пользователем. Но ведь ты не собираешься тут же пытаться внести изменения в эти записи. Будет ведь какой-то период времени на ознакомление и внос изменений пользователем. Где гарантия, что в этот период статус блокировки записи не изменится? Вдруг именно в момент просмотра данных одним пользователем другой как раз и заблокировал (или снял блокировку) эту запись.

Как следствие - проверять статус блокировки надо в момент попытки самому заблокировать запись.

В идеале, лучше организовать программу таким образом, чтобы время любой блокировки было как можно меньше. Идеально для этого подходит оптимистическая буферизация. Правда, несколько усложняется процесс сохранения внесенных изменений.