Използвате автономна транзакция, за да заобиколите факта, че тригерът не може да направи запитване към своята таблица. Попаднахте на прословутата грешка в изменящата се таблица и открихте, че декларирането на тригера като автономна транзакция прави грешката да изчезне.
Няма късмет за вас, това изобщо не решава проблема:
- Първо, всяка транзакционна логика се губи. Не можете да отмените промените в
suscription_factмаса, те са обзаведени , докато основната ви транзакция не е и може да бъде отменена. Така че вие също сте загубили целостта на данните си. - Тригерът не може да види новия ред, защото новият ред все още не е ангажиран! Тъй като тригерът се изпълнява в независима транзакция, той не може да види неосъществените промени, направени от основната транзакция:ще попаднете на напълно грешни резултати.
Ето защо никога не трябва да правите бизнес логика в автономни транзакции. (има легитимни приложения, но те са почти изцяло ограничени до регистриране/дебъгване).
Във вашия случай трябва или да:
- Актуализирайте логиката си, така че да не се налага да прави запитвания към вашата таблица (актуализиране на
suscription_factсамо ако новият ред е по-скорошен от старата стойност, съхранена вid_date_unsuscription). - Забравете за използването на бизнес логика в задействания и използвайте процедура, която актуализира всички таблици правилно или използвайте изглед, защото тук имаме ясен случай на излишни данни.
- Използвайте заобиколно решение, което действително работи (от Том Кайт) .
Горещо препоръчвам да използвате (2) тук. Не използвайте тригери за кодиране на бизнес логиката. Те са трудни за писане без грешки и още по-трудни за поддържане. Използването на процедура гарантира, че целият подходящ код е групиран на едно място (пакет или процедура), лесен за четене и следване и без непредвидени последствия.
