Hallo zusammen,
kennt jemand einen eleganten Weg, um Rekursionen in Triggern zu vermeiden?
Konkret habe ich einen geänderten Datensatz A. Diese Änderungen werden an Datensatz B übertragen. Da sich B aber nun auch geändert hat, versucht dieser auch A zu ändern. Ich habe bislang keine charmante Lösung für diese Probleme. In MSSQL gibt es ja TRIGGER_NESTLEVEL().
In den Monitoring-Tabellen gibt es den CALL_STACK. Ich weiß aber nicht, ob mir das hier weiterhelfen kann. Hat jemand eine Idee?
Dank und Gruß
Martin
Rekursionen in Triggern vermeiden
Moderator: thorben.braun
- martin.koeditz
- Beiträge: 500
- Registriert: Sa 31. Mär 2018, 14:35
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
Wie wäre es mit RDB$Set_Context und RDB$Get_Context?
Aber auch der Nested Level beim SQL-Server kann da durchaus negativ sein.
Denn eigentlich musst du nur den zu ändernden Inhalt prüfen bevor du einen Update machst.
Alternativ kannst du auch die Where-Klausel ja ergänzen:
... where key.... and Fx <> NeuerInhalt
Somit löst dieser Update dann keinen Trigger aus.
Aber auch der Nested Level beim SQL-Server kann da durchaus negativ sein.
Denn eigentlich musst du nur den zu ändernden Inhalt prüfen bevor du einen Update machst.
Alternativ kannst du auch die Where-Klausel ja ergänzen:
... where key.... and Fx <> NeuerInhalt
Somit löst dieser Update dann keinen Trigger aus.
- martin.koeditz
- Beiträge: 500
- Registriert: Sa 31. Mär 2018, 14:35
Gute Idee.Wie wäre es mit RDB$Set_Context und RDB$Get_Context?
Manchmal ist es zu einfach...Alternativ kannst du auch die Where-Klausel ja ergänzen:
... where key.... and Fx <> NeuerInhalt
Somit löst dieser Update dann keinen Trigger aus.

Danke dir.
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH