Я не могу сказать, что видел эту конкретную ошибку, но я задаюсь вопросом, могло ли это быть сохранено в .suo файле, связанном с Вашим решением. .suo - то, где дорожки VS, какие файлы Вы имели открытый ранее, поэтому возможно, он отслеживает отказавшие также. Вы могли бы попытаться переименовать или удалить тот файл и затем перезагрузить решение видеть, уходит ли ошибка. К сожалению, те файлы не совершенно человекочитаемы, поэтому если это оказывается местоположением, это не может быть тривиально для определения, какой файл был виновным.
Вы можете написать процедуру с FOR UPDATE NOWAIT и вернуть сообщение об ошибке, когда строка заблокирована:
SQL> CREATE OR REPLACE PROCEDURE do_something(p_id NUMBER) IS
2 row_locked EXCEPTION;
3 PRAGMA EXCEPTION_INIT(row_locked, -54);
4 BEGIN
5 FOR cc IN (SELECT *
6 FROM some_table
7 WHERE ID = p_id FOR UPDATE NOWAIT) LOOP
8 -- proceed with what you want to do;
9 NULL;
10 END LOOP;
11 EXCEPTION
12 WHEN row_locked THEN
13 raise_application_error(-20001, 'this row is locked...');
14 END do_something;
15 /
Procedure created
Теперь давайте создадим небольшой пример с двумя сеансами:
session_1> select id from some_table where id = 1 for update;
ID
----------
1
session_2> exec do_something(1);
begin do_something(1); end;
ORA-20001: this row is locked...
ORA-06512: at "VNZ.DO_SOMETHING", line 11
ORA-06512: at line 2
session_1> commit;
Commit complete
session_2> exec do_something(1);
PL/SQL procedure successfully completed
Это непросто и непонятно, но информация доступна в представлениях V $ LOCK
и V $ SESSION
.
Однако, если вы чувствуете необходимость использовать что-то подобное как часть вашего обычного кода приложения, вам нужно подумать еще раз. Приложения не должны заботиться о том, как база данных выполняет блокировку. Если вы зашли в тупик, вам необходимо реструктурировать запросы, чтобы их не было.