"Sicherer" Trigger

[Mephisto84]

Hallo allerseits,
ich habe eine Frage.
Ich will in einem Trigger in Tabelle A die Werte in Tabelle B ändern.
Die Daten in Tabelle A sind sehr sehr wichtig.
Wie kann ich denn sicherstellen, dass die Daten auf jeden Fall in Tabelle A stehen bleiben, wenn der Trigger auf die Nase fällt?

Bei einem after insert/update trigger wird doch dann ein roleback gemacht oder nicht?

Grüße,
Mephi

[dimitri]

Wie kann ich denn sicherstellen, dass die Daten auf jeden Fall in Tabelle A stehen bleiben, wenn der Trigger auf die Nase fällt?

Sofern Du keine autonome Transaktion im Trigger verwendest (und das sollte man tunlichst nicht machen), wird die Änderung, die dieses Statement verursacht hat bei einem Fehler im Trigger wieder zurückgerollt. Das ist in innerhalb eines Trigegrs nicht anders als außerhalb.

Dim

[Mephisto84]

Hallo dimitri,
danke für deine Antwort.

Also ich kenne mich mit DB-Pogrammierung nicht soo gut aus, komme eher aus der Anwendungsentwicklung... Und dort würde ich den betreffenden Code catchen und die Exception zurückhalten, damit der Ablauf für Tabelle A nicht gestört wird.
Ist sowas denn möglich in Oracle?

Noch mal mein Ziel anders beschrieben:
Ich will verhindern, dass Probleme bei dem Update der Tabelle B zu Störungen in Tabelle A führen.
Ob die Daten mal nicht in Tab B geupdatet werden odet nicht ist egal. Wichtig sind die Daten in Tab A.

Grüße,
Mehi

Edit: Es geht auch nur um einen Update-Trigger. Der Hinweis mit dem Insert-Trigger in meinem ersten Posting war unsinn.

[dimitri]

Ist sowas denn möglich in Oracle?

Natürlich. Indem Du eine Exception Clause einbaust.



Dim

[jogi01]

Sofern Du keine autonome Transaktion im Trigger verwendest (und das sollte man tunlichst nicht machen), ...
Dim

tach zusammen...

wieso sollte man dies "zunlichst" nicht auf trigger-ebene machen?

es gibt diverse anwendungsbeispiele dafür, wo man gar nicht umhin kommt,
AUTONOMOUS TRANSACTION zu verwenden.

z. B.
Trigger dürfen kein COMMIT absetzen!
wenn man jedoch unabhängig einer transaktion, eine weitere abschliessen muss, die wiederum dur einen trigger ausgelösst wurde...

nur muss man sehr genau wissen was man da tut!

greetz

Jogi

[dimitri]

wieso sollte man dies "zunlichst" nicht auf trigger-ebene machen?

Wenn Du in einem Trigger via autonome transaction ein Commit absetzt, wird die Änderung auch persistiert, wenn die äußere Transaktion zurückgerollt wird, bleibt die andere Änderung trotzdem stehen.

nur muss man sehr genau wissen was man da tut!

Richtig und wer weiß was er tut hält sich auch an diese beiden Grundsätze:
1. Keine fachliche Logik in Triggern, die gehört da nicht hin.
2. Keine Autonomen Transaktionen mit einer Ausnahme: Logging für Fehlersuche etc.
3. Kein EXCPETION WHEN OTHERS ohne Logging und oder anschließendes RAISE

Dim

[jogi01]

Wenn Du in einem Trigger via autonome transaction ein Commit absetzt, wird die Änderung auch persistiert, wenn die äußere Transaktion zurückgerollt wird, bleibt die andere Änderung trotzdem stehen.

Jepp. ich weis! bin auch schon länger dabei!

Richtig und wer weiß was er tut hält sich auch an diese beiden Grundsätze:
1. Keine fachliche Logik in Triggern, die gehört da nicht hin.
2. Keine Autonomen Transaktionen mit einer Ausnahme: Logging für Fehlersuche etc.
3. Kein EXCPETION WHEN OTHERS ohne Logging und oder anschließendes RAISE
Dim

Bevor wir uns über solche "Grundsätze" unterhalten, sollten wir festlegen über welches Code-Object wir uns hier unterhalten.
Und welche Philosophie man verfolgt.

ich gebe dir in sofern recht dass der Trigger-Code schlank sein soll, und nicht mit DECLARE PRAGMA AUTONOMOUS_TRANSACTION beginnen sollte.

jedoch aufrufe von Packages sind in meinen augen völlig legitim. und diese können wiederum autonom sein.

was EXCEPTIONS betrifft, darf es in meinen augen keinen codeteil geben ohne entsprechendes EXCEPTION-handling.

BTW:
Sorry! aber woher hast du denn diese "Grundsätze"?
Steven Feuerstein ist bestimmt einer herrausragenden köpfe.
doch was er schreibt sind ratschläge, und nicht die 10 Gebote.
ich wusste nicht dass es "Grundsätze der DB-Programmierung gibt". und wenn es die gäbe, würde es doch ORACLE schon unterbinden, oder?

ciao

jogi

[dimitri]

Jepp. ich weis! bin auch schon länger dabei!

Schön, einen weiteren alten Hasen dabei zu haben :-)

jedoch aufrufe von Packages sind in meinen augen völlig legitim. und diese können wiederum autonom sein.

Richtig, allerdings sollte man beachten, dass da nicht gegen Grundsatz 1 verstößt

Sorry! aber woher hast du denn diese "Grundsätze"?

Jahrelange Erfahrung als Chefentwickler in einem Projekt mit einer 2TB Datenbank mit ca. 1000 Tabellen als Kernstück, samt angeschlossener Hostsysteme und dezentraler Clients sowie ca. 10 Kollegen, denen man hin und wieder mal gut zureden muss, damit diese Anwendung auch in 2 Jahren noch wartbar ist.

Steven Feuerstein ist bestimmt einer herrausragenden köpfe.

Ich halt mich da eh eher an Tom Kyte.

und wenn es die gäbe, würde es doch ORACLE schon unterbinden, oder

Dein Auto hindert dich auch nicht daran auf der Autobahn in die falsache Richtung zu fahren.

Dim