2
2 Tabellen mit je einem Trigger UPDATE
Hallo,
ich habe mit Hilfe paar User hier eine schicke Lösung gebaut.
Per Trigger und MERGE Befehl wird eine Tabelle A überwacht, auf INSERT und UPDATE.
Sobald dies geschieht, feuert der Trigger bestimmte Daten in eine Tabelle B.
Nun wird die Tabelle B bearbeitet und anschließend wird nun in einer Spalte ein TODO=1 gesetzt.
Ein weiterer Trigger für Tabelle B soll nun ebenfalls Änderungen auf UPDATE überwachen,
damit ich diese Daten wieder zurückschreiben kann in Tabelle A.
Leider schaffe ich mir wohl damit eine Schleife:
Gibt es einen Trick diese Schleife zu umgehen, dass Trigger A in Tabelle A nicht anschlägt?
Ja ich könnte kurz Trigger A deaktivieren, laufe aber dann Gefahr, dass Daten nicht übertragen werden in Tabelle B.
Danke
ich habe mit Hilfe paar User hier eine schicke Lösung gebaut.
Per Trigger und MERGE Befehl wird eine Tabelle A überwacht, auf INSERT und UPDATE.
Sobald dies geschieht, feuert der Trigger bestimmte Daten in eine Tabelle B.
Nun wird die Tabelle B bearbeitet und anschließend wird nun in einer Spalte ein TODO=1 gesetzt.
Ein weiterer Trigger für Tabelle B soll nun ebenfalls Änderungen auf UPDATE überwachen,
damit ich diese Daten wieder zurückschreiben kann in Tabelle A.
Leider schaffe ich mir wohl damit eine Schleife:
Die maximale Schachtelungsebene für gespeicherte Prozeduren, Funktionen, Trigger oder Sichten wurde überschritten (Limit ist 32).Gibt es einen Trick diese Schleife zu umgehen, dass Trigger A in Tabelle A nicht anschlägt?
Ja ich könnte kurz Trigger A deaktivieren, laufe aber dann Gefahr, dass Daten nicht übertragen werden in Tabelle B.
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 399153
Url: https://administrator.de/forum/2-tabellen-mit-je-einem-trigger-update-399153.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
2 Kommentare
Neuester Kommentar
Hi,
du kannst auch Columns überwachen oder gezielt im Trigger auf Änderungen in Spalten reagieren. Denke der MERGE ist zu grobschlächtig. Du hast ja noch andere Optionen, um Änderungen festzustellen. COLUMNS_UPDATED geht über alle beliebigen Spalten (SUBSTRING nicht vergessen, um Spalten >8 zu übewachen).
Du hast auch Zugriff auf den vorherigen Spaltenwert. Die inserted und deleted Tabellen halten alles zur Laufzeit fest. Du kannst somit die Tabellen auch mit JOIN vereinen und im WHERE Part auf Änderungen prüfen. Dann wird nur der Wert weggeschrieben, wenn alle Bedingungen erfüllt sind. Der neue Wert löst auch den anderen Trigger nicht aus, wenn die Spalte garnicht erst überwacht wird.
Das folgende Beispiel wurde verwendet, da die Software auch bei Lesezugriff immer die Datenfelder der jeweiligen Programm-Maske upgedated hat. Unabhängig davon ob Daten geändert wurden oder nicht. Somit war COLUMNS_UPDATED wertlos, da immer positiv.
Du musst darauf auchten nur die Spalten zu überwachen, die einen Trigger auslösen sollen. Sonst geht es hin und her.
du kannst auch Columns überwachen oder gezielt im Trigger auf Änderungen in Spalten reagieren. Denke der MERGE ist zu grobschlächtig. Du hast ja noch andere Optionen, um Änderungen festzustellen. COLUMNS_UPDATED geht über alle beliebigen Spalten (SUBSTRING nicht vergessen, um Spalten >8 zu übewachen).
Du hast auch Zugriff auf den vorherigen Spaltenwert. Die inserted und deleted Tabellen halten alles zur Laufzeit fest. Du kannst somit die Tabellen auch mit JOIN vereinen und im WHERE Part auf Änderungen prüfen. Dann wird nur der Wert weggeschrieben, wenn alle Bedingungen erfüllt sind. Der neue Wert löst auch den anderen Trigger nicht aus, wenn die Spalte garnicht erst überwacht wird.
Das folgende Beispiel wurde verwendet, da die Software auch bei Lesezugriff immer die Datenfelder der jeweiligen Programm-Maske upgedated hat. Unabhängig davon ob Daten geändert wurden oder nicht. Somit war COLUMNS_UPDATED wertlos, da immer positiv.
Du musst darauf auchten nur die Spalten zu überwachen, die einen Trigger auslösen sollen. Sonst geht es hin und her.
INSERT INTO xxx.dbo.auditE_BerichtHz
(audit_log_type, audit_pat_num,
audit_kurz_sd,
audit_verlauf1,
[...])
SELECT 'OLD',
del.pat_num,
del.kurz_sd,
del.verlauf1,
[...]
FROM deleted del
INNER JOIN inserted ins ON del.pat_num=ins.pat_num
WHERE ins.verlauf1<>del.verlauf1 OR
[...]
ins.kurz_sd<>del.kurz_sd; 
Danke für den Hinweis, diesen kann ich sicher noch gebrauchen!
Mein Problem war ein anderes, in Tabelle A wurde Spalte B überwacht und in eine Tabelle B übertragen.
In Tabelle B wurde diese Spalte B temporär geändert und dann wieder zurück in Tabelle A Spalte B geschrieben.
Der Trigger verursachte somit eine Schleife, die Lösung war für mich:
Mein Problem war ein anderes, in Tabelle A wurde Spalte B überwacht und in eine Tabelle B übertragen.
In Tabelle B wurde diese Spalte B temporär geändert und dann wieder zurück in Tabelle A Spalte B geschrieben.
Der Trigger verursachte somit eine Schleife, die Lösung war für mich:
IF ((SELECT TRIGGER_NESTLEVEL()) > 1)
RETURN
