Trigger soll nur beim letzten Änderungsschritt ausgeführt werden

[Avhy]

Hallo,

ich grüble derzeit über folgendem Problem:

Auf einer Tabelle soll ein Trigger das UPDATE überwachsen und bei einer erfolgten Änderung den aktuellen Stand der betroffenen Zeile in eine zweite Tabelle sichern. Soweit noch kein Problem.

Das übergeordnete Programm geht jedoch wie folgt vor:

Der User wählt "Ändern" auf der Obernfläche aus. Im SQL wird die Tabelle das erste Mal geändert, ein Feld wird von 0 auf 1 gesetzt, der Satz wird gesperrt. Erstes Update.

Nun gibt der User die gewünschten Änderungen ein, speichert.
Im SQL wird der Satz entsprechend geändert - zweites Update.

Der gesperrte Satz wird wieder freigegeben, das Sperrflag von 1 auf 0 getzt - drittes Update.

Also eine usergetätigte Änderung zieht 3 Updates im SQL nach sich.

Nun möchte ich natürlich nicht 3x den Satz gesichert haben, sondern nur einmal. Idealweise beim 3.Update.

Die Änderungszeit zu überwachen bringt nichts, weil sie mindestens im Sekundenbereich abweicht. Nur das Datum natürlich auch nichts, weil ein Satz ja mehrfach am Tag geändert werden könnte.

Irgendwie stehe ich auf dem Schlauch und suche noch nach einer guten Idee.... kennt jemand evtl. das Problem? Und hat ne gute Lösung im Ärmel?

Fragende Grüße, Avhy.

[Andreas Kosch]

Hallo,

Nun möchte ich natürlich nicht 3x den Satz gesichert haben, sondern nur einmal.

diese Anforderung kollidiert nicht mit dem mehrfachen Ausführen des Triggers. Der Trigger kann über IF UPDATE(spaltenamen) bzw. über IF (COLUMNS_UPDATED()..) nachprüfen, ob das Sperrflag im 3. Schritt beschrieben wird. In der virtuellen Tabelle Inserted steht dann der neue Wert der Spalte und in der virtuellen Tabelle Deleted der alte Wert. Somit kann der Trigger den Datensatzinhalt nur dann kopieren, wenn das Sperrflag von 1 auf 0 geändert wird.

[Avhy]

Hallo,

also kann ich mit update(Spaltenname) speziell abfangen, ob genau dieses eine Feld geändert wurde?

Super! Das würde echt schon wieder eine ganze Reihe Probleme lösen....

Muß ich gleich ausprobieren gehen... was man damit wohl alles antellen könnte...

Danke für Deine Antwort!

[Markus Kinzler]

Dann werte doch im Trigger, dieses Feld aus.

[Avhy]

Das spezielle Feld lässt sich so nicht auswerten, weil es in einer andern Tabelle liegt.

Hab's jetzt mal mitprotokolliert und der Ablauf ist wie folgt:

- Tabelle SPERREN wird der Sperrflag gesetzt
- Tabelle 1 wird upgedatet
- Tabelle 2 wird upgedatet
- Tabelle 3 wird upgedatet
- Tabelle 4 wird upgedatet
- Tabelle 1 wird upgedatet
- Tabelle SPERREN wird der Sperrflag gelöscht.

Wenn ich den Upgrade-Trigger auf der Tabelle 1 habe, dann wird der 2x angestoßen.

Aber - und da half mir nun der Hinweis if update (Feldname) weiter!

Beim zweiten Update der Tabelle 1 wird nur ein Feld upgedatet. Beim ersten Update werden alle Felder beschrieben (egal ob sie geändert wurden oder nicht).

Also hab ich den Trigger auf Tabelle 1 mit einem Feld als if-Bedingung gekoppelt. Und der Trigger triggert nun schön zuverlässig nur beim ersten Mal. Yeah!

Nun klappt's, daß beim 1.Update auf Tabelle 1 diese select * from deleted auf eine Hilfstabelle kopiert wird, dazu dann die Tabelen 2-4. Damit hab ich den unveränderten Stand "eingefroren".

Beim 2. Update triggert der Trigger nicht nochmal - und ich hab wirklich nur den einen Satz "hoch und trocken eingelagert".

*Zufrieden-bin*

[Markus Kinzler]

Dann frag doch in diesem Trigger das Flag ab.

[Avhy]

Geht nicht - weil sowohl beim 1. als auch beim 2. Update der Tabelle 1 beidesmal das Flag = 1 ist. Es wird erst nach dem 2.Update wieder gelöscht.