Ausführen von DML-Triggern

Aktualisiert: 05. Dezember 2005

AFTER-Trigger werden niemals ausgeführt, wenn eine Einschränkungsverletzung auftritt; diese Trigger können somit nicht für Verarbeitungen verwendet werden, die Einschränkungsverletzungen verhindern.

INSTEAD OF-Trigger werden anstelle der Aktion ausgeführt, die den Trigger ausgelöst hat. Diese Trigger werden ausgeführt, nachdem die inserted- und deleted-Tabellen erstellt wurden, die die Änderungen an den Basistabellen widerspiegeln, jedoch bevor andere Aktionen erfolgen. Sie werden vor Einschränkungen ausgeführt, um Verarbeitungen als Ergänzung zu Einschränkungsaktionen auszuführen.

Falls ein für eine Tabelle definierter INSTEAD OF-Trigger eine Anweisung für die Tabelle ausführt, die normalerweise den INSTEAD OF-Trigger erneut auslösen würde, wird der Trigger nicht rekursiv aufgerufen. Stattdessen wird die Anweisung so verarbeitet, als ob in der Tabelle kein INSTEAD OF-Trigger vorhanden wäre, und die Kette der Einschränkungsvorgänge und AFTER-Triggerausführungen wird gestartet. Wenn beispielsweise ein Trigger als INSTEAD OF INSERT-Trigger für eine Tabelle definiert ist und der Trigger eine INSERT-Anweisung für dieselbe Tabelle ausführt, ruft die durch den INSTEAD OF-Trigger ausgeführte INSERT-Anweisung den Trigger nicht erneut auf. Die INSERT-Anweisung, die durch den Trigger ausgeführt wird, startet das Ausführen der Einschränkungsaktionen und löst alle für die Tabelle definierten AFTER INSERT-Trigger aus.

Falls ein für eine Sicht definierter INSTEAD OF-Trigger eine Anweisung für die Sicht ausführt, die normalerweise den INSTEAD OF-Trigger erneut auslösen würde, wird der Trigger nicht rekursiv aufgerufen. Stattdessen wird die Anweisung als Änderungen an den zugrunde liegenden Basistabellen der Sicht aufgelöst. In diesem Fall muss die Sichtdefinition alle Einschränkungen für eine aktualisierbare Sicht erfüllen. Eine Definition aktualisierbarer Sichten finden Sie unter Ändern von Daten über eine Sicht. Wenn ein Trigger beispielsweise als INSTEAD OF UPDATE-Trigger für eine Sicht definiert ist und der Trigger eine UPDATE-Anweisung ausführt, die auf dieselbe Sicht verweist, ruft die durch die INSTEAD OF-Trigger ausgeführte UPDATE-Anweisung den Trigger nicht erneut auf. Die von dem Trigger ausgeführte UPDATE-Anweisung wird für die Sicht so verarbeitet, als ob in der Sicht kein INSTEAD OF-Trigger vorhanden wäre. Die von der UPDATE-Anweisung geänderten Spalten müssen in eine einzige Basistabelle aufgelöst werden. Jede Änderung an einer zugrunde liegenden Basistabelle startet die Kette des Anwendens von Einschränkungen und Auslösen von für die Tabelle definierten AFTER-Triggern.

Der Aufwand an Verarbeitungsleistung für einen DML-Trigger ist normalerweise gering. Die beim Ausführen eines DML-Triggers aufgewendete Zeit wird größtenteils für Verweise auf andere Tabellen benötigt, die sich im Arbeitsspeicher oder auf dem Datenbankmedium befinden können. Die Tabellen deleted und inserted befinden sich immer im Arbeitsspeicher. Der Speicherort anderer Tabellen, auf die vom Trigger verwiesen wird, bestimmt den Zeitaufwand, der für den Vorgang erforderlich ist.

Hinweis:
Das Verwenden von Cursorn in DML-Triggern wird wegen einer möglichen Beeinträchtigung der Leistung nicht empfohlen. Verwenden Sie statt Cursorn rowsetbasierte Logik, um einen DML-Trigger zu erstellen, der sich auf mehrere Zeilen auswirkt.

Ausführen von DML-Triggern und partitionierte Sichten

Die Art, wie UPDATE- und DELETE-Trigger in SQL Server 2005 in Tabellen, die einer partitionierten Sicht unterliegen, ausgelöst werden, unterscheidet sich von der Weise, wie sie in SQL Server 2000 ausgelöst werden. Wenn in SQL Server 2000 eine UPDATE- oder DELETE-Anweisung an eine partitionierte Sicht ausgegeben wird, sei es lokal oder verteilt, werden sämtliche für die Basistabellen dieser Sicht definierte UPDATE- oder DELETE-Trigger ausgelöst. Hierzu gehören auch Trigger in Tabellen, die nicht vom Update- oder Löschvorgang betroffen sind. In SQL Server 2005 wird ein UPDATE- oder DELETE-Trigger nur dann ausgelöst, wenn die Basistabelle, in dem der Trigger definiert ist, vom Update- oder Löschvorgang betroffen ist. Dieses Verhalten gilt gleichermaßen für AFTER- und INSTEAD OF-Trigger.

Nehmen wir z. B. die partitionierte Sicht PV, die aus Feldern der Tabellen T1 und T2 besteht. Zusätzlich sind in T1 und T2 UPDATE-Trigger definiert. Eine UPDATE-Anweisung, die in SQL Server 2000 für die partitionierte Sicht PV ausgegeben wird, die sich nur auf die Zeilen in T1 auswirkt, verursacht das Auslösen der UPDATE-Trigger sowohl in T1 als auch in T2. In SQL Server 2005 werden nur die in T1 definierten UPDATE-Trigger ausgelöst.

In der folgenden Tabelle finden Sie eine Zusammenfassung der Verhaltensänderungen.

Einfüge-, Update- und Löschvorgang in einer lokalen partitionierten Sicht

Einfüge-, Update- und Löschvorgang in einer verteilten partitionierten Sicht

Siehe auch

Konzepte

Verwenden der Tabellen inserted und deleted
Kaskadierende Einschränkungen der referenziellen Integrität
Verwenden von geschachtelten Triggern

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf