Du bruger en autonom transaktion til at omgå det faktum, at en trigger ikke selv kan forespørge i sin tabel. Du er stødt på den berygtede mutationstabelfejl, og du har opdaget, at hvis du erklærer triggeren som en autonom transaktion, forsvinder fejlen.
Der er dog ingen held, dette løser slet ikke problemet:
- For det første går enhver transaktionslogik tabt. Du kan ikke rulle ændringerne tilbage på
suscription_facttabel, er de forpligtede , mens din hovedtransaktion ikke er og kunne rulles tilbage. Så du har også mistet din dataintegritet. - Udløseren kan ikke se den nye række, fordi den nye række ikke er blevet aktiveret endnu! Da triggeren kører i en uafhængig transaktion, kan den ikke se de uforpligtede ændringer foretaget af hovedtransaktionen:du vil løbe ind i helt forkerte resultater.
Det er derfor, du aldrig bør lave nogen forretningslogik i autonome transaktioner. (der er legitime applikationer, men de er næsten udelukkende begrænset til logning/fejlretning).
I dit tilfælde skal du enten:
- Opdater din logik, så den ikke behøver at forespørge i din tabel (opdatering af
suscription_factkun hvis den nye række er nyere end den gamle værdi, der er gemt iid_date_unsuscription). - Glem alt om at bruge forretningslogik i triggere og brug en procedure, der opdaterer alle tabeller korrekt, eller brug en visning, for her har vi et tydeligt tilfælde af overflødige data.
- Brug en løsning, der rent faktisk virker (af Tom Kyte) .
Jeg vil kraftigt anbefale at bruge (2) her. Brug ikke triggere til at kode forretningslogik. De er svære at skrive uden fejl og endnu sværere at vedligeholde. Brug af en procedure garanterer, at al den relevante kode er samlet på ét sted (en pakke eller en procedure), let at læse og følge og uden uforudsete konsekvenser.