Привет!
Вот какой вопрос. Надо недопустить наличия дубликатов в таблице А. Обойтись CHECK и/или уникальный индекс не могу. Потому как уникальными должны быть комбинации из A и еще одной таблицы B. Да и то, не уникальными, а только одна комбинация может встретиться один раз, а другие сколько угодно. То есть только одна активная запись - сколько угодно неактивных.

Для этих целей был написан триггер, который смотрел есть ли уже активная запись и если есть - посылал на фиг. Но при попытке его использования оракл меня послал, сказав че-то про "mutating table". Вопрос - почему я не могу посмотреть (только почитать) изменяемую таблицу?

Смежный вопрос. Я перенес проверку в код добавления новой записи. Типа, сначала поверяю - потом пишу. Но вот здесь я хотел бы заблокировать изменяемые строки от параллельного изменения. Как это сделать?
Я знаю, что есть SELECT ... FOR UPDATE. Я бы хотел им воспользоватся только для установки блокировки. Но в PL|SQL я должен написать INTO - а вот этого мне бы и хотелось избежать. Можно ли как-то написать типа так LOCK ROWS WHERE ID IN (SELECT ...)?

Какие существуют методы блокировки вообще в оракле?

И еще - LOCK TABLE для меня не подходит. Так как коммит в сессии может пройти не скоро (пользователь должен сделать Save) - я не могу заблокировать все строки в таблице.

Еще один уточняющий вопрос. Есть код, который таким макаром пытается блокировать нужные строки без их выборки.

DECLARE
CURSOR LockerCursor IS SELECT ... FOR UPDATE;
BEGIN
OPEN LockerCursor;
CLOSE LockerCursor;

... do somthing

CLOSE не освободит блокировку? Это произойдет только при завершении транзакции?

Есть ли какой-нибудь "идиоматический" способ блокировки нужных строк без их выборки? Может какой-то пакедж?

Ага, спасибо.

А DBMS_LOCK я посмотрел - это аналог EnterCriticalSection/LeaveCriticalSection. Точнее мьютесов.
Все компоненты приложения должны синхронизировать свой доступ к ресурсу с помощью именованной блокирвки - в моем случае (бардак полный) - это абсолютно нереально. Поэтому приходиться производить "железную" проверку.

Нет, вопрос оказался не снят.

Вот что говорит руководство (и FK тут не причем с точки зрения руководства).

1) Определение mutating table
A mutating table is a table that is currently being modified by an UPDATE, DELETE, or INSERT statement, or it is a table that might need to be updated by the effects of a declarative DELETE CASCADE referential integrity constraint.

2) Ограничение на какие триггеры?
For all row triggers, or for statement triggers that were fired as the result of a DELETE CASCADE.

3) Что за ограничение?
The SQL statements of a trigger cannot read from (query) or modify a mutating table of the triggering statement.

4) То есть независимо от наличия или отсутсвия FK, триггер не может читать mutating таблицу.

5) Я практически проверил - МОЖЕТ. Для таблицы без FK. И без DELETE CASCADE

6) И не может для таблицы с ... тоже без FK. И без DELETE CASCADE

Руководство врет. Но почему такая разница в двух очень похожих триггерах?