Mehrere Trigger nacheinander

[study11]

Ich grüße euch liebe Datenbankexperten,

weißt jemand, wo ich nachlesen könnte, was passiert, wenn ich zwei Trigger für eine Tabelle habe, die auf die gleichen Ereignisse reagieren sollen?
Ich hab es getestet. Hab zwei INSERT-Trigger für die gleiche Tabelle angelegt. Sie werden tatsächlich nacheinander ausgeführt. Ich brauche aber ein bisschen mehr Infos zum Thema. Beim Googeln leider nichts gefunden. Nur, dass ab Oracle 11 man FOLLOWS verwenden kann. Die Lösung wird aber für die Versionen 9,10 und Ms Sql entwickelt.

Ich freue mich falls euch etwas zum Thema einfällt.

Gruß

[Ralf Jansen]

Warum? Auf die Reihenfolge von Triggern angewiesen zu sein hört sich nach einem schweren Designproblem an. Wenn nur irgend wie möglich solltest du, auch wenn es Aufwand bedeutet, das so umändern das das unnötig wird.

Üblicherweise ist die Reihenfolge von Triggern undefiniert und wenn ihr für verschiedene Subsysteme entwickeln wollt wäre das auf jedenfall die Grundlage von der ihr ausgehend das System designen solltet.
Beim SQL Server kannst du maximal den ersten und letzten After Trigger bestimmen der Rest ist undefiniert.

[study11]

Ich soll aus einem Programm auf die DB zugreifen, eine kleine Umgebung aufbauen für die Speicherung von Änderungen.

Z.B. ich will jetzt eine bestimmte Tabelle überwachen -> starte das Programm -> wähle die Tabelle aus -> wähle die Felder, die Änderungen von denen ich speichern will aus -> sage, welcher Text die Daten begleiten muss-> speichere das ganze....
so bearbeite ich alle Tabellen....
Dafür sollen Trigger auch automatisch angelegt werden.... ich weiß, das ich idealerweise bereits bestehenden Trigger auf der DB ändern muss, aber hier ist es nicht der Ausweg.... weil die Trigger in der unterschiedlichen DB sehen unterschiedlich aus und den Quelltext aus den ins Programm auszulesen hilft auch nicht wirklich, da ich dabei nicht alles berücksichtigen kann..... ich kann z.B. auslesen, was für Trigger für die Tabelle existiert....das ist insert-Trigger, ok das passt, da ich sowieso delete-Trigger anlege und das wird funktionieren..... aber wenn es ein delete-Trigger bereit existiert...was mache ich dann??

wie noch kann ich mein Problem lösen????

(( ich glaube, das hier nur die Datenbankfunktionen hilfreich sein könnten, irgendwas zur Verwaltung von Triggern,Priorisierung oder etwas änliches.... aber ich hab bis jetzt ncihts passendes gefunden ((

[Ralf Jansen]

Wenn du eine Änderungsverfolgung haben willst würde ich wohl eher auf die Transaktionslog setzen und versuchen die auszuwerten und nicht die DB mit Triggern vollkleistern.

[study11]

Danke Ralf für die schnelle Reaktion
könntest du mir kurz erklären, wie das gemacht werden kann....
muss ich meine Sql-Strings im Quellcode an Tausenden Stellen ändern, um Transaktionsrahmen zu setzen?
habe bis jetzt leider nicht viel damit zu tun....

[Ralf Jansen]

Erklären kann ich dir das konkret nicht für Qracle. Da fehlt mir die Erfahrung. Aber jede Datenbank zeichnet ihren Änderungsverlauf im Normalfall mit auf um z.B. für ein Point-In-Time Recovery den Zustand der Datenbank auf jeden beliebigen Zeitpunkt setzen zu können. Dieses Transaktionslog sollte auswertbar sein. Im SQL Server gibt es dafür diverse Tools. Selbst gemacht würde man mit einem DBCC LOG Aufruf beginnen, den return dann aufbereiten um dann die aufbereiteten Daten entsprechen den eigenen Wünschen zu filtern.

muss ich meine Sql-Strings im Quellcode an Tausenden Stellen ändern, um Transaktionsrahmen zu setzen?

Nein. Jede Änderung der DB sollte im Transaktionslog auftauchen. Ob du eine Transaktion explizit oder nur implizit gestartet hast ist irrelevant.

[akretschmer]

Üblicherweise ist die Reihenfolge von Triggern undefiniert

Moment: in PostgreSQL werden sie alphabetisch angearbeitet. Das ist (in PG) klar dokumentiert. Ich weiß nicht, ob das nach einer SQL-Spec ist und wie das in anderen Systemen läuft, denke aber, daß das definiert ist.

[Ralf Jansen]

Moment: in PostgreSQL werden sie alphabetisch angearbeitet. Das ist (in PG) klar dokumentiert.

Ich will nicht ausschließen das das in PostgreSQL so ist und wir werden bestimmt auch noch andere Datenbanken wo irgendwas definiert ist finden.

Aber lass mich kurz mal an dir und PostgreSQL prüfen wie ~klar~ das definiert ist
Stellen wir uns vor es gibt die Insert Trigger x, y, z auf einer Tabelle. Aufgrund einer bestimmten Logik wird Trigger y ab und zu einen weiteren Satz in die eigene Tabelle Inserten. Wird jetzt erst z für den eigentlichen Insert gefeuert oder x für den weiteren Insert? In welcher Reihenfolge kommen dann die weiteren Triggeraufrufe den jeder Trigger wird ja jetzt mehrfach aufgerufen? Kommt es vielleicht auch noch drauf an ob es After, Before oder sogar InsteadOf Trigger waren? Und was ist wenn die Trigger nicht durch einen simplen einzelnen Insert ausgelöst wurden sondern durch einen Masseninsert? Muß man dann auch noch unterscheiden ob die Trigger als 'for each row' oder 'for each statement' definiert sind? Traust du dir zu alle denkbaren Triggerdefinitionen zu durchdenken und durch Kombinatorik aller Möglichkeiten letztlich die Ausführungsreihenfolge in Regeln niederzuschreiben? Und das dann natürlich glaubhaft für jede PostgreSQL Installation?

Also ich würde mich einfach auf den Standpunkt stellen das ist Zufall da es mir kaum möglich ist den kausalen Zusammenhang lückenlos nachzuvollziehen.

[dimitri]

In Oracle ist die Abarbeitung der Trigger genau beschrieben: Oracle bis Version 10: Undefiniert. Aber Version 11 gibt es das neue Schlüsselwort FOLLOWS, mit dem man die Reihenfolge der Triggerausführung festlegen kann.

[dimitri]

Noch ein Tipp: In Oracle 11 gibt es das sog. Flashback Data Archive. Allerdings als Option zur Enterprise Edition. http://www.oracle.com/webfolder/tech...bda/index.html