<< Prozedur mit Verwendung der SUBSTRING Funktion | IBExpert | Firebird 3.0 DDL Trigger >>

Die deutschsprachige Dokumentation wird seit dem 26. Juli 2016 nicht mehr gepflegt. Aktuelle und vollständige Dokumentation finden Sie auf der englischsprachigen Webseite: IBExpert Documentation

Trigger

Ein Trigger ist eine unabhängige Reihe von Befehlen, abgespeichert als ein eigenständiges Programm (SQL Skript) in der Datenbank. Trigger werden automatisch in der Datenbank ausgeführt, wenn bestimmte Events (Ereignisse) eintreten. Beispielsweise ist es vor einer Eingabe möglich, zu überprüfen, ob ein Primärschlüssel bereits vorhanden ist oder nicht und, falls notwendig, einen Wert durch einen Generator zuzuordnen. Diese Ereignisse sind Ereignisse einer Datenbank, Tabelle oder Zeile.

Trigger sind die sogenannte Datenbank-Polizei, die für die Datenbank-Integrität und Datenbank-Sicherheit unerlässlich sind, da sie die Einhaltung der, durch den Datenbankentwickler programmierten Regeln durchsetzen. Sie können einen oder mehrere Ausführungsbefehle enthalten. Sie können auch als Alarm (= event alerter) verwendet werden, der einen bestimmten Namen zum Firebird/InterBase^® Event Manager sendet.

Trigger empfangen keine Eingabeparameter und geben keine Werte zurück.

Ein Trigger wird nie direkt aufgerufen, sondern alle Trigger, die mit einer Tabelle und einer bestimmten Operation assoziert sind, werden automatisch ausgeführt, wenn eine Anwendung oder User versucht einen INSERT, UPDATE oder DELETE an einem Datensatz in der Tabelle vorzunehmen. Trigger, die für einen UPDATE an einem nicht-updatable View definiert sind, werden ausgeführt, auch wenn keinen Update stattfindet.

Die Sequenz, in der Trigger definiert werden, wird von TRIGGER POSITION bestimmt und es können verschiedenen Triggertypen festgelegt werden (siehe unten).

Sie können im DB Explorer, mit dem IBExpert Rechtsklickmenü im Tabelleneditor oder dem Feldeditor, oder direkt im IBExpert SQL Editor erzeugt, bearbeitet und gelöscht werden.

Seit Firebird 1.5 stehen Universaltrigger (die gleichzeitig für INSERT und/oder UPDATE und/oder DELETE verwendet werden können) zur Verfügung und in Firebird 2.1 wurden Datenbank-Trigger eingeführt (weitere Informationen siehe unten). Firebird 2.1 unterstützt auch alternative Syntaxe für die CREATE TRIGGER-Anweisung, die mit SQL2003 übereinstimmen. Weiteres finden Sie im Kapitel SQL2003 compliance for CREATE TRIGGER in den Firebird 2.1 Release Notes.

Vor Firebird 1.5 wurde ein Trigger, der eine PLAN-Anweisung enthielt, vom Kompilierer zurück abgelehnt. Seit Firebird 1.5 kann ein gültiger Plan eingeschlossen und verwendet werden.

Ein Beispiel:

 CREATE TRIGGER TEST_TRIG FOR TEST
 ACTIVE BEFORE INSERT POSITION 0
 AS
 begin
    if (new.id is null) then
       new.id=gen_id (GLOB_ID,1);
 end

Es können mehrere Trigger für ein Event erzeugt werden. Der Parameter POSITION bestimmt die Sequenz, in der der Trigger ausgeführt wird.

Trigger sind fast identisch mit Stored Procedures. Der Hauptunterschied ist die Art, wie sie aufgerufen werden. Trigger werden automatisch aufgerufen, wenn eine Änderung in einer Zeile, in einer Tabelle, oder bestimmte Datenbank-Aktionen eintreten. Das meiste, was über Stored Procedures gesagt wurde, trifft auch auf Trigger zu und sie haben dieselbe Sprache, PSQL. PSQL ist eine vollständige Programmiersprache für Prozeduren und Trigger. Sie enthält:

• SQL Datenmanipulationsanweisungen: INSERT, UPDATE, DELETE and singleton SELECT.
• SQL Operatoren und Expressions, sowie auch Generatoren und UDFs, die mit der rufenden Anwendung verlinkt sind.
• Leistungsfähige SQL-Erweiterungen wie Anweisungen, Kontrollfluss-Anweisungen, Variablen, Event-Posting-Anweisungen, Exceptions und Fehlerbehandlungsanweisungen.

Ein Zusammenfassung der PSQL Befehle befindet sich im Kapitel, Stored procedure and trigger language.

zurück zum Seitenanfang

Datenbank-Trigger

Datenbank-Trigger wurden ab der Version 2.1 in Firebird eingeführt. Dies sind benutzerdefinierte PSQL-Module, die definiert werden können, um auf verschiedenen Verbindungsebenen und Transaktionsebenen zu feuern. Dadurch wird es beispielsweise möglich, ein Protokoll relativ schnell und einfach einzurichten.

Datenbank-Triggertypen

Datenbank-Trigger können von folgenden Datenbanktypen gefeuert werden:

CONNECT	Die Datenbankverbindung ist hergestellt, eine Transaktion beginnt, Trigger werden gefeuert - Exceptions führen zum Rollback der Transaktion, Verbindung wird gelöst und an den Client zurückgegeben. Abschließend wird die Transaktion committed.
DISCONNECT	Eine Transaktion wird gestartet, Trigger werden gefeuert - Exceptions führen zu Rollback der Transaktion, Verbindung wird gelöst und angehalten. Die Transaktion wird committed und die Verbindung gelöst.
TRANSACTION START	Trigger werden in der neu erzeugten Benutzertransaktion gefeuert - Exceptions werden an den Client zurückgegeben und ein Rollback der Transaktion erfolgt.
TRANSACTION COMMIT	Trigger werden in der Committing-Transaktion gefeuert - Exceptions führen zum Rollback des Trigger Savepoints, der Commit-Befehl wird abgebrochen und eine Exception an den Client zurückgegeben. Bei Zwei-Phasen-Transaktionen werden die Trigger in PREPARE und nicht in COMMIT gefeuert.
TRANSACTION ROLLBACK	Triggerwerden in der Rollback-Transaktion gefeuert - Änderungen werden zusammen mit der Transaktion zurückgenommen und Exceptions werden gestoppt.

Nur der SYSDBA oder der Datenbankbesitzer können:

• Datenbank-Trigger definieren
• diese ausschalten für eine neue Verbindung durch:
  • new isc_dpb_no_db_triggers tag
  • new -no_dbtriggers umschalten in den Firebird Utilities

In IBExpert können Datenbanktrigger genauso wie tabellengebundene Trigger erzeugt, bearbeitet und gelöscht werden (siehe Neuer Trigger). Schalten Sie einfach in der Symbolleiste auf Datenbank-Trigger, um Zugriff auf die Optionen der Datenbank-Trigger zu erhalten:

Legen Sie fest, wer Zugriff auf Ihre Anwendung erhalten soll, oder rufen Sie eine Exception hervor, wenn bestimmte, unerwünschte Anwendung auf Ihre Datenbank zugreifen wollen. Datenbanktrigger sind auch sehr schöne Features für Protokolle, die sie es Ihnen beispielsweise ermöglichen, Ihr eigenes Login Mapping mit IP-Adresse zu erstellen, usw.

Ein Beipiel eines Datenbank-Triggers (Quelle Firebird 2.1 What's New, von Vladyslav Khorsum):

Beispiel für einen ON CONNECT-Trigger

 isql temp.fdb -user SYSDBA -pass masterkey
 Database: temp.fdb, User: SYSDBA 
 SQL> SET TERM ^ ; 
 SQL> CREATE EXCEPTION EX_CONNECT 'Forbidden !' ^ 
 SQL> CREATE OR ALTER TRIGGER TRG_CONN ON CONNECT 
 CON> AS 
 CON> BEGIN 
 CON> IF (<bad user>) 
 CON> THEN EXCEPTION EX_CONNECT USER || ' not allowed !'; 
 CON> END ^ 
 SQL> EXIT ^ 

 isql temp.fdb -user BAD_USER -pass ... 
 Statement failed, SQLCODE = -836 
 exception 217 
 -EX_CONNECT 
 -BAD_USER not allowed ! 
 -At trigger 'TRG_CONN' line: 5, col: 3 
 Use CONNECT or CREATE DATABASE to specify a database 
 SQL> EXIT;

Wenn Sie Probleme mit einem ON CONNECT-Trigger haben, sodass niemand mehr mit der Datenbank verbinden kann, verwenden Sie die Umschaltung auf -no_dbtriggers in den Firebird Utilities:

 isql temp.fdb -user SYSDBA -pass masterkey 
 -nodbtriggers Database: temp.fdb, User: SYSDBA 
 SQL> ALTER TRIGGER TRG_CONN INACTIVE; 
 SQL> EXIT;

Datenbank-Trigger können schnell und einfach in IBExpert im Triggereditor definiert werden (siehe unten).

Siehe auch:
englischsprachig:
Firebird 2.1 Release Notes: Database triggers

Zurück zum Seitenanfang

Tabellen-Trigger

Tabellen-Triggertypen

Triggertypen beziehen sich auf den Triggerstatus (ACTIVE oder INACTIVE), die Triggerposition (BEFORE oder AFTER) und den Operationstyp (INSERT, UPDATE oder DELETE).

Sie werden nach der Tabellendefinition oder dem Viewnamen und vor dem Triggerkörper definiert.

ACTIVE oder INACTIVE

ACTIVE oder INACTIVE wird zum Zeitpunkt der Erzeugung eines Triggers festgelegt. ACTIVE ist Standard, sofern keines dieser Schlüsselwörter festgelegt wurde. Ein inaktiver Trigger führt nicht zur Ausführung.

BEFORE oder AFTER

Ein Trigger muss definiert werden, um entweder BEFORE (vor) oder AFTER (nach) einer Operation zu feuern. Ein BEFORE INSERT-Trigger feuert, bevor eine neue Zeile tatsächlich in eine Tabelle eingegeben wird; ein AFTER INSERT-Trigger feuert, nachdem die Zeile eingegeben wurde.

BEFORE-Trigger werden im Allgemeinen zu zwei Zwecken eingesetzt:

1. Sie können verwendet werden, um zu bestimmen, ob die Operation fortgeführt wird, d.h. bestimmte Parameter können gestestet werden, um zu bestimmen, ob die Zeile eingegeben, aktualisert oder gelöscht werden soll oder nicht. Wenn nicht kann eine Exception aufgerufen werden und ein Rollback der Transaktion erfolgt.
2. BEFORE-Trigger können ebenfalls verwendet werden, um zu bestimmen, ob es verbundene Zeilen gibt, die von dieser Operation betroffen sind. Zum Beispiel, kann ein Trigger verwendet werden, um automatisch Verkäufe wieder zuzuordnen, bevor ein Verkäufer gelöscht wird.

AFTER-Trigger werden im Allgemeinen zur Aktualisierung der Werte von Spalten in verbundenen Tabellen verwendet, die eingegeben, aktualisiert oder gelöscht wurden. Zum Beispiel wird die Spalte PERCENT_CHANGE in der Tabelle SALARY_HISTORY mit einem AFTER UPDATE-Trigger in der Tabelle EMPLOYEE aktualisiert.

Zusammenfassend kann man sagen: Verwenden Sie BEFORE bis alle Operationen abgeschlossen wurden. Der Datenbank-Trigger SET_CUST_NO der Datenbank EMPLOYEE ist ein Beispiel für einen BEFORE INSERT, da eine neue Kundennummer generiert wird, bevor der Datensatz eingegeben wurde.

Wenn Manipulationen einer Tabellendaten abgeschlossen wurden, bevor andere Daten geprüft oder geändert wurden, verwenden Sie einen AFTER-Trigger. Der Datenbank-Trigger SAVE_SALARY_CHANGE der Datenbank EMPLOYEE ist ein Beispiel für einen AFTER UPDATE-Trigger, da die Datenänderungen bereits abgeschlossen wurden, bevor der Trigger feuert.

INSERT, UPDATE, DELETE

Es muss definiert werden, ob ein Trigger bei einem der Schlüsselwörter INSERT, UPDATE oder DELETE feuert.

1. Ein INSERT-Trigger feuert bevor oder nachdem eine Zeile in eine Tabelle eingegeben wurde.
2. Ein UPDATE-Trigger feuert, wenn eine Zeile in der Tabelle modifiziert wird.
3. Ein DELETE-Trigger feuert, wenn eine Zeile aus einer Tabelle gelöscht wird.

Wenn derselbe Trigger bei mehr als einer Operation feuern soll, muss ein Universaltrigger definiert werden. Vor Firebird 1.5 waren Trigger begrenzt auf Eingabe-, Update- oder Löschaktionen, aber jetzt muss nur noch ein einziger Trigger für all diese Aktionen erzeugt werden. Zum Beispiel:

 AS
    BEGIN
       if (new.bez<>'')
       then new.bez=upper(new.bez);
    END

' ' UPPER gilt für INSERT und UPDATE-Operationen.

Bitte beachten Sie, dass Sonderzeichen, wie die deutschen Umlaute, nicht erkannt werden und in Großschreibung geändert werden, da diese Zeichen technisch gesehen, wie Sonderzeichen und nicht wie Buchstaben behandelt werden.

Weitere Informationen zu NEW-Variablen finden Sie unter NEW- und OLD-Kontextvariablen.

NEW- und OLD-Kontextvariablen

In Triggern (aber nicht in Stored Procedures) bietet Firebird/InterBase^® zwei Kontextvariablen an, die Informationen enthalten, wie in eine Zeile Eingaben, Änderungen oder Löschungen zu erfolgen haben:

1. OLD.columnName bezieht sich auf die aktuellen oder vorherigen Werte in einer Zeile, die aktualisiert oder gelöscht wurde. Es ist nicht relevant für INSERT-Trigger.
2. NEW.columnName bezieht sich auf die neuen Werte in einer Zeile, die eingegeben oder akualisiert wurde. Es ist nicht relevant für DELETE-Trigger.

Unter Verwendung der OLD. und NEW.-Werte können Sie ganz einfach Historien-Datensätze erzeugen, die Summe der prozentualen Änderungen eines numerischen Werts errechnen, Datensätze in anderen Tabellen finden, die entweder mit dem OLD. oder NEW.-Wert übereinstimmen oder so ziemlich alles andere tun, was Ihnen dazu einfällt. Bitte beachten Sie, dass NEW.-Variablen nicht in einem BEFORE-Trigger modifiziert werden können; seit der Einführung von Firebird 2.0, ist es nicht mehr so einfach, sie in einem AFTER-Trigger zu ändern. OLD.-Variablen können nicht modifiziert werden.

Es ist möglich, von diesen Trigger-Variablen aus zu lesen oder zu schreiben.

Neu seit Firebird 2.0: Restrictions on assignment to context variables in triggers (Einschränkungen bei der Zuweisung zu Kontextvariablen in Triggern)

• Zuweisung zu OLD-Kontextvariablen sind jetzt für jede Art von Trigger verboten.
• Zuweisungen zu NEW-Kontextvariablen in AFTER-Trigger sind ebenfalls verboten.

Tipp: Wenn der unerwarteter Fehler Cannot update a read-only column (Kann eine Nur-Lesen-Spalte nicht aktualisieren) auftritt, dann ist der Verstoß gegen einer dieser Einschränkungen die Ursache dieser Fehlermeldung.

zurück zum Seitenanfang

DDL Trigger

DDL Trigger sind neu in Firebird 3.0. Sie können geschrieben werden, um bei der Änderung oder Löschung von Datenbankobjekten auszuführen. Der Zweck eines DDL Triggers ist es, Einschränkungen auf Benutzer zu setzen, die versuchen ein DDL Objekt zu erstellen, zu ändern oder zu löschen. Sie können mehr über DDL Trigger in den Firebird 3.0.0 Alpha 1 Release Notes (Auszug aus der ersten Version veröffentlicht am 23. Juli 2013).

IBExpert unterstützt DDL Trigger seit Version 2014.01.01.

zurück zum Seitenanfang

Neuer Trigger

Es gibt zahlreiche Wege einen Trigger in IBExpert zu erzeugen.

1. Die Verwendung des IBExpert Datenbankmenüpunkts Neuer Trigger oder das entsprechende Symbol in der Symbolleiste Neues Datenbankobjekt.
2. Aus dem DB Explorer per Rechtsklick auf dem markierten Triggerzweig der entsprechenden verbundenen Datenbank (oder Tastenkombination [Strg + N]).

Beide Optionen öffnen den Triggereditor:

• (1) Name: der Triggername kann wunschgemäß geändert werden, wenn Sie den vorgegebenen Namen nicht verwenden möchten. Wie bei allen Datenbankobjekten, ist es wichtig, Regeln zu festzulegen, die Ihnen und anderen Entwicklern in den kommenden Jahren helfen werden, Objekte einfach zu erkennen, zu erkennen, wohin diese gehören und ihre Beziehung zu anderen Objekten. Die oben stehende Abblidung zeigt einen BEFORE INSERT- Trigger. Der Name setzt sich zusammen aus dem Tabellennamen, BI ist die Abkürzung für Before Insert und 10 bezeichnet die festgelegte Position.
• (2) Für Tabelle: wählen Sie die Tabelle oder den Viewnamen aus der Drop-Down-Liste.
• (3) Position: 255 Positionen sind pro Tabelle erlaubt, (angefangen bei 0, bis zu 254). Es können auch mehrere Trigger in einer Tabelle dieselbe Feuerposition haben, wenn es irrelevant welcher Trigger zuerst feuert. Da die Positionen keine fortlaufenden Nummer sein müssen, ist es ratsam, eine Regel zu entwickeln, beginnend mit, sagen wir, 50 und in 10er oder 20er Intervallen nummerierend. Damit können Sie jederzeit neue Trigger eingeben und positionieren, ohne alle anderen vorhandenen Triggerpositionen anpassen oder ändern zu müssen. Es ist sehr wichtig, die Ausführungsreihenfolge Ihrer Trigger aus logischen Gründen aufzusplitten. Zum Beispiel der before insert-Loggingtrigger in einer Tabelle muss den Primärschlüssel des Datensatzes kennen, sodass der before insert Primärschlüssel-Trigger zuerst feuern muss.
• (4) Ist Aktiv: aktivieren/deaktivieren Sie die Checkbox entsprechend.
• (5) Typ: legen Sie den Triggertyp fest als BEFORE oder AFTER und markieren Sie die Aktion(en) INSERT, UPATE und/oder DELETE, wie gewünscht. Wenn alle drei Optionen aktiviert werden, erzeugt dies automatisch einen Universaltrigger.
• (6) Triggerkörper: Der Triggerkörper kann im SQL-Fenster vervollständigt werden.

3. Ein Trigger kann auch im Tabelleneditor oder im Vieweditor erzeugt werden, auf der Seite Trigger durch Auswahl der gewünschten BEFORE/AFTER-Pperationwn und per Rechtsklickmenüpunkt Neuer Trigger. Dadurch öffnet sich der oben gezeigte Neuer Trigger-Editor.
4. Oder im Feldeditor auf der Seite Autozähler. Beipielsweise kann ein Triggertext für einen neuen Generator einfach und schnell mit den Menüpunkten Bearbeite Feld / Autozähler, Erzeuge Generator und dann Erzeuge Trigger erzeugt werden.

Wer die direkte SQL-Eingabe bevorzugt; die CREATE TRIGGER-Anweisung hat folgende Syntax:

 CREATE TRIGGER <trigger_name>
 FOR <table_name>
 <keywords_for_trigger_type>
 AS
 <local_variable_declarations>
 BEGIN
 <body_of_trigger>
 END

Der Triggername muss eindeutig und einmalig innerhalb einer Datenbank sein und unterliegt den Firebird/InterBase^® Namensgebungsbedingungen für Spalten, Tabellen, Views und Prozeduren.

Trigger können nur für eine einzelne Datenbank oder Tabelle oder einen aktualisierbaren View definiert werden. Trigger, die für mehrere Tabellen gelten sollen, müssen durch eine Stored Procedure aufgerufen werden. Dies kann einfach durch Erzeugung einer Stored Procedure, die sich auf die Trigger bezieht, geschehen. Weiteres finden Sie im Kapitel Using procedures to create and drop triggers in der Firebird Development using IBExpert Dokumentation.

Trigger feuern, wenn eine zeilenbasierende Operation in der benannten Tabelle oder View stattfindet.

zurück zum Seitenanfang

Lokale Variablendeklarationen

Trigger verwenden die gleichen Erweiterungen in SQL, die Firebird/InterBase^® für Stored Procedures anbietet. Daher gilt die folgende Anweisung auch für Trigger:

• DECLARE VARIABLE
• BEGIN … END
• SELECT … INTO : variable_list
• Variable = Expression
• /* comments */
• EXECUTE PROCEDURE
• FOR select DO …
• IF condition THEN … ELSE …
• WHILE condition DO …

Wie bei Stored Procedures, beinhaltet die CREATE TRIGGER-Anweisung SQL-Anweisungen, die konzeptionell innerhalb dieser Anweisung eingebettet sind. Damit Firebird/InterBase^® einen Trigger korrekt parsen und interpretieren kann, benötigt die Datenbank-Software einen Weg, den CREATE TRIGGER zu stoppen, der sich von dem Weg, wie die Anweisung innerhalb der CREATE TRIGGER-Anweisung gestoppt wird, unterscheidet. Dies erfolgt über die SET TERM Anweisung.

Vergessen Sie nicht, abschließend den neuen Trigger mit dem entsprechenden Symbol in der Symbolleiste oder [F9] zu kompilieren und, wenn gewünscht, autmatisch die Rechte zuzuweisen, wiederum mit dem enstprechenden Symbol in der Symbolleiste oder der Tastankombination [Strg + F8].

Da ein Trigger mit einer Tabelle assoziert ist, der Tabelleneigentumer und alle User mit Privilegien auf dieser Tabelle besitzen automatisch die Rechte solche verbundenen Trigger auszuführen.

Trigger können Rechte auf Tabellen zugewiesen werden, genau wie User oder Prozeduren Rechte zugewiesen werden können. Nutzen Sie das Autogrant Rechte -Symbol oder die GRANT-Anweisung: anstatt TO USERNAME verwenden Sie TO TRIGGER trigger_name. Triggerrechte können in ähnlicher Weise aufgehoben werden mittels die %newwin REVOKE-Anweisung.

Wenn ein User eine Aktion ausführt, die einen Trigger auslöst, der Trigger wird die Rechte für die Ausführung seiner Aufgabe besitzen, wenn eine der folgenden Bedingungen zutrifft:

• Der Trigger besitzt die Rechte für die Aktion.
• Der User ist berechtigt, die Aktion auszuführen.

Siehe auch:
englischsprachig:
Data Control Language - DCL

zurück zum Seitenanfang

Erzeuge einen Trigger für einen Generator

Generell wird ein Generator zur Bestimmung eindeutiger Identifizierungsnummern für Primärschlüssel verwendet. Ein BEFORE INSERT-Trigger kann definiert werden, um eine neue ID zu generieren, den aktuallen Wert mit der GEN_ID()-Funktion zu erhöhen und diesen automatisch in das entsprechende Tabellenfeld einzufügen.

Die obige Abbildung zeigt den Feldeditor, gestartet aus dem Tabelleneditor.

Siehe auch:
deutschsprachig:
Generator
Firebird Generatoren-Ratgeber: Generatoren zum Erzeugen eindeutiger Datensatz-IDs

zurück zum Seitenanfang

Erzeuge einen Trigger für einen View

Es ist möglich einen Trigger im Vieweditor auf der Seite Trigger direkt für einen View zu erzeugen. Dies ist besonders interessant für Nur-Lesen-Views. Zum Beispiel BEFORE INSERT, insert into Table1 new_fields und table2 new_data für Felder. BEFORE UPDATES- und BEFORE DELETE-Trigger sollten ebenfalls hinzugefügt werden, um die in dem View vorgenommenen Datenmanipulationen in die entsprechenden Basistabellen zu verteilen.

zurück zum Seitenanfang

Triggereditor

Der Triggereditor kann mit dem IBExpert Datenbankmenüpunkt Neuer Trigger gestartet werden; aus dem DB Explorer, mit dem Rechtsklickmenü oder per Doppelklick auf einen vorhandenen Trigger oder alternativ direkt aus dem View oder der Seite Triggers.

Wenn Sie zum ersten Mal einen Trigger erzeugen, finden Sie weitere Infos unter Neuer Trigger.

Der Triggereditor hat seine eigene Symbolleiste (siehe Symbolleiste Triggereditor) und bietet die folgenden Optionen an:

• Trigger
• Beschreibung
• Abhängigkeiten
• Operationen
• DDL
• Versionshistorie
• Vergleich
• To-Do

Das Menü links in der Symbolleiste bietet zusätzlich die Optionen, Trigger löschen und Triggertabelle editieren [Tabellenname].

Seit IBExpert Version 2015.09.28 werden Firebird 3 CREATE/ALTER/DROP MAPPING-Befehle unterstützt.
Unterstützung von Firebird 3.0 Triggern wurde in IBExpert Version 2015.12.21 implementiert.

Triggerseite

Die erste Seite des Triggereditors ermöglicht die einfache und Schnelle Festlegung des Triggernamens, Tabellen- oder Viewnamens, Position, aktiv/inaktiv und des Triggertyps, mit Hilfe der Pull-Down-Liste, vorausgesetzt der Lazy Mode wurde eingeschaltet:

Wenn Sie das Fenster Variablen nicht in der Mitte sehen können, aktivieren Sie bitte die Checkbox Variables in Grid, zu finden im IBExpert Menü Optionen/ Objekteditor Optionen auf der Seite Triggers Editor.

Wenn der Lazy Mode ausgeschaltet ist, müssen die Informationen im SQL-Fenster definiert werden:

Das SQL-Fenster bietet Vorlagen für beide Standards (für den ganzen Trigger) und den Lazy Mode, wo der Trigger körper eingegeben werden kann. Diese Vorlagen können auf Wunsch geändert werden mit dem IBExpert Menüpunkt Optionen / Hauptvorlagen / New trigger.

Der Code Formatter wurde in der IBExpert Version 2009.03.25 eingeführt. Mit dem Code Formatter können Sie den Quellcode von Views, Triggern und Stored Procedures formatieren. Über den Menüpunkt Code formatting options ... können Sie ein Reihe von Einstellungen für alle oder für einzelne Anweisungen anpassen. Weiteres hierzu finden Sie im IBExpert Menü Optionen unter Code formatting options ....

Wie in allen SQL-Eingabefenstern kann das SQL-Editor-Menü per Rechtsklick aufgerufen werden. Die Tastaturkürzel, die im SQL-Editor zur Verfügung stehen sind hier ebenfalls verfügbar. Diese Optionen können verwendet werden, um eine Vielzahl an Aktionen durchzuführen, zum Beispiel:

• Kommentiere oder Entkommentiere Code mit dem kontextabhänigen Rechtsklickmenü.
• Rücke markierte Codeblöcke mit [Strg + Umschaltg + I] ein und schiebe sie mit [Strg + Umschaltg + U] zurück.

Wenn eein Trigger oder eine Triggeränderung abeschlossen ist, kann mit dem entsprechenden Symbol oder [Strg + F9] kompliliert werden. Wenn Fehler gefunden werden, klicken Sie JA, wenn danach gefragt wird, ob trotzdem kompiliert werden soll, um ein SQL-Fehlerskript (unterhalb des Triggertextes) zu erzeugen, um die Fehlerquelle finden zu können.

Wenn das Problem komplizierter ist, kann die Option Kopiere Skript oder Kopiere Info verwenet werden , bevor abschließend die Aktion zurückgenommen wird (Rollback).

Der Triggereditor hat auch sein eigenes Debug Trigger-Symbol. Mehr Informationen dazu finden Sie unter Debug von Prozeduren und Triggern.

zurück zum Seitenanfang

Beschreibung

Weiteres finden Sie unter Tabelleneditor / Beschreibung.

Abhängigkeiten

Weiteres finden Sie unter Tabelleneditor / Abhägigikeiten.

Operationen

Weiteres finden Sie unter Prozedureneditor / Operationen.

DDL

Weiteres finden Sie unter Tabelleneditor / DDL.

Versionshistorie

Weiteres finden Sie unter Vieweditor / Versionshistorie.

Vergleich

Weiteres finden Sie unter Tabelleneditor / Vergleich.

To-do

Weiteres finden Sie unter Tabelleneditor / To-do.

zurück zum Seitenanfang

Kommentiere Triggerkörper/Entkommentiere Triggerkörper

In bestimmten Situationen kann es notwendig sein, bestimmte Kommentare oder Teile des Triggercodes zu deaktivieren. Es ist möglich, dieses vorübergehend zu tun, ohne das diese Befehle gelöscht werden müssen. Wählen Sie einfach die betreffenden Zeilen im SQL Editor aus und wählen Sie dann entweder das Symbol in der Symbolleiste des Editors:

den Rechtsklickmenüpunkt Kommentiere Ausgewähltes, oder Tastenkombination [Strg + Alt + .]. Dies ändert die Befehlszeile in Kommentare. Der kommentierte Text kann einfach mit dem Symbol Triggertext entkommentieren (oben), dem Rechtsklickmenüpunkt Entkommentiere Ausgewähltes, oder [Strg + Alt + ,].

Es auch möglich das Schnellkommentar Feature in allen IBExpert Code-Editoren zu verwenden: Mit der Tastenkombination [Strg] + [Alt] + [.] (oder dem Rechtsklick-Menüpunkt Kommentiere Ausgewähltes), können Sie schnell die aktuelle Codeauswahl oder den ausgewählten Block kommentieren. Und verwenden Sie den Rechtsklick-Menüpunkt, Entkommentiere Ausgewähltes oder [Strg] + [Alt] + [,] zu unkommentieren.

Es kann nicht nur verwendet werden, um Kommentare und Dokumentationsnotizen zu komplexeren Stored Procedures und Triggern hinzuzufügen, sondern auch, um ausgewählte Codeteile während einer Testphase oder sogar für Kundenanwendungen auszuklammern, wo bestimmte Feature derzeit nicht benötigt werden, aber vielleicht zu einem späteren Zeitpunkt benötigt werden. Der Code kann bei Bedarf einfach durch Entkommentieren wieder eingesetzt werden.

zurück zum Seitenanfang

Bearbeite Trigger

Der Triggerkopf und der Triggerkörper können geändert werden.

Der Triggerkopf kann aktiviert oder deaktiviert werden, oder seine Position (im Verhältnis zu anderen Triggern) geändert werden.

Wenn der Triggerkörper geändert werden muss, ist es nicht notwendig irgendwelche Änderungen am Triggerkopf vorzunehmen, es sei denn, Sie wünschen es natürlich! Obwohl es in diesem Fall möglicherweise mehr Sinn macht, den Trigger zu löschen und einen neuen zu erzeugen. Jede Änderung am Triggerkörper überschreibt den ursprünglichen Inhalt.

Trigger können leicht im Triggereditor im DB Explorer geändert werden. Dieser wird per Doppelklick auf den Triggernamen geöffnet oder mit dem Rechtsklickmenüpunkt Bearbeite Trigger [Strg + O]. Die Kopfinformation kann mit der Drop-Down-Liste zur Änderung der Position, der Checkbox zum Aktivieren/ Deaktivieren und der Drop-Down-Liste zur Wahl des Typen angepasst werden:

(Das Bild zeigt den Lazy Mode). Der Körpertext kann bei Bedarf im SQL-Eingabefeld geändert werden.

Abschließend müssen die überarbeiteten Trigger kompiliert und comitted werden, damit die Änderung gültig wird.

Vermerk: Um ein durch eine Tabellen CHECK-Beschränkung automatisch generierter Trigger zu ändern, verwenden Sie ALTER TABLE, um die CHECK-Definition zu ändern.

Die SQL-Syntax für Änderungen am Trigerkopf lautet wie folgt:

 ALTER TRIGGER name
 [ACTIVE | INACTIVE]
 [{BEFORE | AFTER} {DELETE | INSERT | UPDATE}]
 [POSITION number]

wobei n die neue Positionsnummer ist. Oder um den Triggerkörper zu ändern:

 ALTER TRIGGER <trigger_name>
 AS
 BEGIN
    <new_trigger_body>
 END

Sollten Argumente in der ALTER TRIGGER-Anweisung fehlen, werden ihre aktuellen Werte genommen, d.h. die Werte, die entweder in die CREATE TRIGGER-Anweisung oder in der letzten ALTER TRIGGER-Anweisung definiert wurden.

Ein Trigger kann nur vom Datenbankbesitzer oder vom SYSDBA geändert werden.

Bitte beachten Sie: Jedesmal, wenn Sie CREATE, ALTER oder DROP TRIGGER verwenden, erhöht InterBase^® den Metadatenänderungszähler der entsprechenden Tabelle. Hat der Zähler 255 erreicht, sind keine weiteren Metadatenänderungen mehr möglich und der Tabelle (Sie können jedoch weiter mit den Daten arbeiten). Ein Backup-Restore Zyklus ist notwendig, um den Zähler wieder auf Null zu setzen und damit wieder Metadatenänderungen vornehmen zu können.

Diese obligatorische Bereinigung nach vielen Metadatenänderungen ist an sich sehr nützlich, bedeutet aber auch, dass Benutzer, die normalerweise ALTER TRIGGER verwenden, um Trigger zu deaktivieren, während z.B. einer Bulk-Import.Operation, gezwungen sind, jetzt viel öfter ein Backup/Restore vornehmen zu müssen, als benötigt. Da Änderungen an Triggern keine strukturellen Änderungen an der Tabelle selbst verursachen, erhöht Fírebird (seit Version 1.0) nicht den Tabellenänderungszähler, wenn CREATE, ALTER oder DROP TRIGGER verwendet wird. Eine Sache bleibt jedoch: wenn der Zähler 255 erreicht hat, können Sie keine weiteren Trigger für diese Tabelle erzeugen, ändern oder löschen.

Eine neue Syntax zur Änderung der Trigger, oder zur Erzeugung, falls sie noch nicht vorhanden sind, wurde in Firebird 2.0 eingeführt. Weiters finden Sie unter CREATE OR ALTER TRIGGER.

zurück zum Seitenanfang

Erzeuge Trigger erneut

Neu seit Firebird 2.0: Die DDL-Anweisung RECREATE TRIGGER steht jetzt in DDL zur Verfügung. Die Semantik ist dieselbe, wie für andere RECREATE-Anweisungen.

Siehe auch:
englischsprachig:
RECREATE TRIGGER

Lösche Trigger

Ein Trigger kann nur gelöscht werden, wenn andere Benutzer keinerlei Änderungen an Tabellen vornehmen, für die der Trigger zum Zeitpunkt der Löschung relevant ist. In IBExpert kann ein Trigger aus dem DB Explorer durch Markieren des zu löschenden Triggers und Auswahl des Rechtsklickmenüpunktes Lösche Trigger oder [Strg + Entf] gelöscht werden oder, wenn der Trigger bereits im Trigger Editor geöffnet ist, verwenden Sie das Trigger Editor Menü (durch Anklicken Trigger oben links zu öffnen), Lösche Trigger.

IBExpert bittet um Bestätigung:

bevor der Trigger endgültig gelöscht wird.

Die SQL Syntax lautet:

 DROP TRIGGER <trigger_name>

Alternativ zum Löschen eines Triggers, kann auch der Triggerstatus in INACTIVE geändert werden. Somit verbleibt er in der Datenbank, ist aber nicht fähig zu feuern, kann dafür aber zu einem späteren Zeitpunkt bei Bedarf wieder aktiviert werden.

Ein Trigger kann nur vom Datenbankbesitzer oder vom SYDBA gelöscht werden.

Siehe auch:
deutschsprachig:
Lazy Mode
Generator
View
Debug Prozeduren
Abhängigkeiten
Stored Procedure/Trigger/Viewanalyse
IBE$VERSION_HISTORY Systemtabelle
253 Änderungen in der Tabelle verbleiben
englischsprachig:
Stored procedure and trigger language
Writing stored procedures and triggers
Using procedures to create and drop triggers
Comments
Firebird for the database expert - Episode 1: Indexes
CREATE TRIGGER
ALTER TRIGGER
RECREATE TRIGGER
DROP TRIGGER
Declarative referential integrity versus triggers

zurück zum Seitenanfang
<< Prozedur mit Verwendung der SUBSTRING Funktion | IBExpert | Firebird 3.0 DDL Trigger >>