U gebruikt een autonome transactie om het feit te omzeilen dat een trigger zijn tabel niet zelf kan opvragen. Je bent de beruchte muterende tabelfout tegengekomen en je hebt ontdekt dat het verklaren van de trigger als een autonome transactie ervoor zorgt dat de fout verdwijnt.
Geen geluk voor jou, dit lost het probleem helemaal niet op:
- Ten eerste gaat alle transactielogica verloren. U kunt de wijzigingen op de
suscription_fact. niet terugdraaien tabel, ze zijn toegewijd , terwijl uw hoofdtransactie dat niet is en kan worden teruggedraaid. U bent dus ook uw gegevensintegriteit kwijt. - De trigger kan de nieuwe rij niet zien omdat de nieuwe rij nog niet is vastgelegd! Aangezien de trigger in een onafhankelijke transactie wordt uitgevoerd, kan deze de niet-vastgelegde wijzigingen die door de hoofdtransactie zijn aangebracht niet zien:u zult volledig verkeerde resultaten tegenkomen.
Dit is de reden waarom u nooit bedrijfslogica moet toepassen in autonome transacties. (er zijn legitieme applicaties, maar ze zijn bijna volledig beperkt tot logging/debugging).
In uw geval moet u ofwel:
- Update uw logica zodat deze uw tabel niet hoeft te bevragen (update
suscription_factalleen als de nieuwe rij recenter is dan de oude waarde die is opgeslagen inid_date_unsuscription). - Vergeet het gebruik van bedrijfslogica in triggers en gebruik een procedure die alle tabellen correct bijwerkt of gebruik een weergave, want hier hebben we een duidelijk geval van redundante gegevens.
- Gebruik een oplossing die echt werkt (door Tom Kyte) .
Ik zou sterk adviseren om (2) hier te gebruiken. Gebruik geen triggers om bedrijfslogica te coderen. Ze zijn moeilijk te schrijven zonder fouten en nog moeilijker te onderhouden. Het gebruik van een procedure garandeert dat alle relevante code op één plek is gegroepeerd (een pakket of een procedure), gemakkelijk te lezen en te volgen is en zonder onvoorziene gevolgen.