Ты путаешь INSTEAD OF триггер (на VIEW) и COMPAUND триггер. Последний -- это просто объединение триггеров на разные события в одном куске кода, что удобней при использовании например локальных PL/SQL коллекций для обхода той же мутации.
Типо: в секции BEFORE STATEMENT заполняешь коллекцию текущим состоянием, а затем в секциях BEFORE/AFTER EACH ROW проверяешь не нарушает ли условие конкретная запись (на основании коллекции, чтоб не лезть в таблицу). При этом ты, естественно, не видишь изменений других сеансов (добавленных строк, например) и если не предусмотрена какая-либо сериализация (та же блокировка родительской записи) -- все твоя проверка может пойти лесом

Не спорю, CHECK намного лучше
А еще и индекс на FOREIGN KEY построить

Но это таки пример -- вводить и объяснять новые понятия нет желания

dba123studierenВячеслав Любомудров,

Спасибо. Я понял Вашу мысль. Любое изменение в платежах нужно с помощью триггера отразить в дополнительном поле в контрактах. Если сумма превышает, то тогда и происходит исключение.
ОК. Если не найду другое решение, то так и сделаю.
только внимательней со своим кодом, а то апдейт фк может не сработать, как мне показалось

Все, заклевали
Нафиг я сюда вообще влез

studierenНу допустим, пользователь по конкретному контракту только 1, в смысле если я ввожу данные по одному контракту, то никто параллельно в этот момент не работает с данным контрактам. Соответственно, исключаем возможность других сеансов по конкретной записи. Или другой пример. Допустим я единственный пользователь базы.Такие допущения надо чем-то обеспечить
studierenПочему то в MS SQL Server нет таких проблем вообще.Просто они разные
Когда ты изменяешь несколько строк одним оператором и пытаешься (в триггере для каждой обновленной строки) например, подсчитать сумму в этих строках, то возникает вопрос, на какой момент времени брать значения? Точнее даже какой именно из возможных -- ты не можешь управлять порядком обновления/удаления/вставки строк (при многострочной обработке) и при другом порядке (который выбирает Oracle) результат будет другой.

Возьмем твой пример -- ограничить сумму в 1500
Пусть у нас есть строки со значениями: 1000, 500, -1000
Если мы сделаем UPDATE TABLE SET AMOUNT = AMOUNT*3
То, если строки будут обновляться в прямом порядке, то после обновления первой строки мы получим (1000*3)+(500)+(-1000) = 2500, что уже больше 1500, и значит все плохо, так делать нельзя и т.п.
Если же мы обновляем с конца, то после обновления всех строк получаем (1000*3)+(500*3)+(-1000*3) = 1500, что оказывается неплохо, можно даже сказать, хорошо

Вот от такой неоднозначности тебя Oracle и страхует

studierenВячеслав Любомудров...
Возьмем твой пример -- ограничить сумму в 1500
Пусть у нас есть строки со значениями: 1000, 500, -1000
Если мы сделаем UPDATE TABLE SET AMOUNT = AMOUNT*3
То, если строки будут обновляться в прямом порядке, то после обновления первой строки мы получим (1000*3)+(500)+(-1000) = 2500, что уже больше 1500, и значит все плохо, так делать нельзя и т.п.
Если же мы обновляем с конца, то после обновления всех строк получаем (1000*3)+(500*3)+(-1000*3) = 1500, что оказывается неплохо, можно даже сказать, хорошо

Вот от такой неоднозначности тебя Oracle и страхует

В MS SQL Server когда массово что-то меняете и при этом хотя бы одна запись даёт "сбой", то сервер запрещает все изменения и происходит откат. Жаль, что в ORACLE не так. Ты нихрена не понял
Вопрос в непредсказуемости результата
studierenА вообще обычно юзеры штучно правят записи, массово что-то менять может только админ базы или специалист ИТ.Какое-то извращенное понятие, можно подумать БД разбирается -- обычный это юзер или "специалист ИТ"
На одиночных обновлениях триггер BEFORE ... FOR EACH ROW тоже отработает без ошибки
Именно потому, что результат детерминирован

ElicВячеслав ЛюбомудровНа одиночных обновлениях триггер BEFORE ... FOR EACH ROW тоже отработает без ошибкиВставках.Упс...
Точно