Самодельная проверка : Oracle

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

Вложения

	TblCre.txt (315 байт, 153 просмотров)
	wi_no_or.zip (5.3 Кб, 124 просмотров)

Думаю, надо перенести в https://olegon.ru/showthread.php?t=1664

Давайте выслушаем комментарии. Я пока не пробовал, но смутило упоминание о неустойчивой работе. Пусть автор принимает решение. Релиз?

1. Что то мне не очень понятно использование временной таблицы. (производительность?)
2. Попробовать стандартную проверку переделать под себя?
3. Рекомендую вместо временной таблицы курсоры с аналитическими функциями (явно подымет производительность)

1. Теперь либо я не понял задачи, но зачем тебе кроме триггера на SMDOCUMENTS ещё два?
2. для обхода мутации использовать PAT?

1,3. В 70 магазинах до сих пор 8i SE так что PL/SQL таблицы и аналитика не поможет.
2. Как?
"1. Теперь либо я не понял задачи, но зачем тебе кроме триггера на SMDOCUMENTS ещё два?" - именно для обхода мутации
И что такое РАТ ?

[ ➜ ]

Автономная транзакция не подходит (проверено).

Меня больше интересует как "2. Попробовать стандартную проверку переделать под себя? " ?!?!?

ну на счет автономной транзакции это ты зря. сам делал, по поводу два, это декриптуешь процедуру и свои условия включаешь, у меня так пара проверок работает, это проще и гораздо дешевле чем С+ просить (пока объяснишь что хочешь, проще застрелится, я не понимаю с+, они готовы на ровном месте буксовать когда вопрос ничего не стоит)
я себе уже файлик изменений свой завел для этого, дабы после обновлений восстановить

И не забываешь, что эта процедура является нарушением лицензионного соглашения. :(

Алгоритм криптования/декриптования в Oracle описан самим Oracle.
Если вы добавляете/модифицируете индекс это тоже нарушение лицензионного соглашения (в каждой второй базе хозяйничаем не так ли? кто скажет что это настройка производительности, то смею вас заверить в коде Супермага PL/SQL можно тоже много оптимизировать. в чем отличие?), думаю что можно опустить формальности в данном случае С+ получает свои деньги за поддержку и не думаю что будет в таких случаях претензии предъявлять.