По большому счету, никак

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

Т.е. только обработка отказа в обновлении данных.

Ну, "штатно", сброс данных из Remote View происходит по команде TableUpdate(), вот в случае отказа в обновлении и анализируешь причину отказа. Примерно так:


В массиве laError будет сообщение об ошибке собственно SQL-сервера. Точно не скажу, какой там в этом случае будет номер ошибки, но попробуй поэксперимнтировать. Думаю, быстро определишь.

Первый элемент массива всегда будет иметь значение 1526 (ошибка ODBC), а вот 5 элемент массива - это уже код ошибки собственно SQL-сервера.

Та же самая логика, если ты делаешь сброс изменений через SPT-курсоры (командой SQLExec()).

Spavel_74А гденибуть можно посматреть коды Ошибок SQL-сервера с их объяснением?
В HELP к соответсвующему серверу. Если речь идет о MS SQL, то его Help называется Books OnLine (сокращенно BOL).

Впрочем, в массиве сформированном по AERROR(), кроме кода ошибки будет и текст сообщения об ошибке, которое сформирует SQL-сервер (второй и третий элементы). Обычно этого текста вполне достаточно, чтобы понять причину ошибки.