Gibt es eine Möglichkeit, innerhalb einer SP einen bestimmten Trigger kurzzeitig auf inactive zu setzen?
alter trigger TRIGGER_NAME inactive;
geht natürlich nicht innerhalb einer SP.
Auch wenn ich das als Execute statement ('...'); versuche. Gibt zwar keinen Fehler, aber geht auch nicht.
Ich vermute ja mal, dass es nicht geht, weil das Deaktivieren von Triggern DDL ist, und man die wohl nicht einfach mal soeben innerhalb PSQL machen kann.
Temporäres Sperren von Triggern
Moderator: thorben.braun
Bestimmet DDL's kann man nur per dynamischem SQL erledig.
https://firebirdsql.org/refdocs/langref ... cstat.html
Das schöne ist, DDL per Execute unerliegt meist keiner Einschränkung.
Allerdings muss für die Änderung von Table-Metadaten die Tabelle exclusiv im Zugriff sein.
https://firebirdsql.org/refdocs/langref ... cstat.html
Das schöne ist, DDL per Execute unerliegt meist keiner Einschränkung.
Allerdings muss für die Änderung von Table-Metadaten die Tabelle exclusiv im Zugriff sein.
Vielen Dank für die rasche Antwort.
Exklusiver Zugriff auf die Tabelle, dessen Trigger ich temporär umgehen wollte, kann natürlich nicht gewährleistet werden. Demzufolge muss ich einen anderen Weg finden.
Und die Aussage
Exklusiver Zugriff auf die Tabelle, dessen Trigger ich temporär umgehen wollte, kann natürlich nicht gewährleistet werden. Demzufolge muss ich einen anderen Weg finden.
Und die Aussage
ist ja auch ziemlich eindeutig.Although this form of EXECUTE STATEMENT can also be used with all kinds of DDL strings (except CREATE/DROP DATABASE), it is generally very, very unwise to use this trick in order to circumvent the no-DDL rule in PSQL.
Nun ja, in unserer BI-Lösung wird sehr viel zur Laufzeit mit dynamischem DDL gearbeitet.
Dies geht nun mal ausschließlich auf diesem Weg.
Zusätzlich benötige ich da noch eine Sperrlösung, weil 2 DDL's gleichzeitg häufig zum DB-Crash führen.
Aber das erledige ich mit einem "Select * from MyTable for update".
Dieser parkt alle meine DDL-Befehle und sequentialisiert diese.
Mittels autonomous transaction stelle ich auch das Problem der Satzversionen sicher, die auch bei den Systemtabellen zur Anwendung kommt.
Es ist aber nun mal korrekt, dass man Trigger in einer Shared-Umgebung nicht umgehen kann und das ist auch besser so.
Allerdings könntest du Session-Variablen erstellen, die die normalen User/Apps nicht kennen, und deine Trigger prüfen über die Sessionvariable ob sie was tun sollen oder nicht.
Dies geht nun mal ausschließlich auf diesem Weg.
Zusätzlich benötige ich da noch eine Sperrlösung, weil 2 DDL's gleichzeitg häufig zum DB-Crash führen.
Aber das erledige ich mit einem "Select * from MyTable for update".
Dieser parkt alle meine DDL-Befehle und sequentialisiert diese.
Mittels autonomous transaction stelle ich auch das Problem der Satzversionen sicher, die auch bei den Systemtabellen zur Anwendung kommt.
Es ist aber nun mal korrekt, dass man Trigger in einer Shared-Umgebung nicht umgehen kann und das ist auch besser so.
Allerdings könntest du Session-Variablen erstellen, die die normalen User/Apps nicht kennen, und deine Trigger prüfen über die Sessionvariable ob sie was tun sollen oder nicht.
-
colaflasche
- Beiträge: 16
- Registriert: Fr 6. Mär 2020, 16:32
Du könntest mit rdb$get_context einen Kontext abfragen, den du vorher setzt. Wenn er gesetzt ist, springst du per exit aus dem triggern.
Davon muss aber jede connection wissen. Der context ist je connection. Bestehende connections kannst du per Event informieren.
Davon muss aber jede connection wissen. Der context ist je connection. Bestehende connections kannst du per Event informieren.
Ich denke, die Deaktivierung des Triggers soll nur für die aktve Sitzung bzw. Transaktion gelten. Systemweit wäre ja fatal, da die SP ja nicht generell aufgerufen wird.
Somit ist dein Vorschlag per Context durchaus geeignet, da dies eine Vereinbarung zwischen Trigger und SP ist.
Somit ist dein Vorschlag per Context durchaus geeignet, da dies eine Vereinbarung zwischen Trigger und SP ist.