TSQL-trigger erstellen fehl

Habe ich einige code, der in einem after insert-trigger, die möglicherweise fehlschlagen. Ein solcher Fehler ist nicht entscheidend und sollte nicht rollback der Transaktion. Wie kann ich den Fehler abfangen innerhalb der trigger-und der rest der Transaktion ordnungsgemäß ausgeführt?

Das Beispiel unten zeigt, was ich meine. Der trigger absichtlich erzeugt eine Fehlerbedingung mit dem Ergebnis, dass die original-insert ( "1" ) nie Einfügungen in die Tabelle. Try/Catch hat nicht scheinen, um den trick zu tun. Eine ähnliche, ältere stack overflow Frage nicht Ertrag eine Antwort außer "verhindern, dass die Fehler auftreten in den ersten Platz" - das ist nicht immer möglich/einfach ist.

Irgendwelche anderen Ideen?

create table test 
(
  a int not null
);
go

create trigger testTrigger on test 
after insert as 
begin 
  insert into test select null;
end;
go

insert into test values ( 1 );

Warum Try/Catch nicht funktioniert?
da Verstöße gegen die Vorgaben innerhalb der Trigger doom der Transaktionen.

InformationsquelleAutor BuschnicK | 2010-01-29

2

Einen trigger nicht Versagen können, und haben immer noch die Transaktion roll forward. Sie haben ein paar Optionen, um sicherzustellen, dass die trigger nicht scheitern.

1 - können Sie sicherstellen, dass die nach nicht scheitern, durch duplizieren der Logik, die zur überprüfung der Einschränkungen und nicht versucht, eine operation gegen die Auflagen:

d.h.
```
INSERT INTO test WHERE val IS NOT NULL
```
2 - Sie können verschieben die potenziell fehlerhaften Aktion, indem Sie mit Hilfe des queue-design-Muster, wo die Handlungen, die möglicherweise oder möglicherweise nicht fehl, werden in der Warteschlange von enqueueing zu einem Tisch, wo die enqueueing der Betrieb kann unmöglich scheitern.

d.h.
```
INSERT INTO ACTION_QUEUE (action, parameters) VALUES ('INSERT INTO TEST', val)
```
- Ich fürchte, dass dieser Begriff war der einzige Weg. Es ist so schwer. Bitte siehe mein Kommentar zu Quassnoi die Antwort von unten.
- Making-Trigger ist einer der mehr invasive Dinge, die Sie tun können, in einem system. Es ist Teil des Datenbank-Schemas für die Durchsetzung der Datenbank Verhalten und Sie tun dies in einer fremden Datenbank. Sie haben Ihren Platz, aber ich glaube nicht, dass diese Verwendung geeignet ist, WENN Sie kann nicht garantieren, dass Sie sich gut benehmen. Ehrlich gesagt, wenn Sie einen trigger als Ihre einzige Mechanismus, um Schiff verpasst, wenn der Auslöser war unbemerkt scheitert, werden Ihre änderungen nicht ausgeliefert, doch ist die Transaktion abzuschließen und verlieren Sie die Daten ändern "message", wie würden Sie die re-sync Ihre Daten zuverlässig überhaupt?
- Sie wäre besser dran, auf der Suche in eine Art von change data capture oder anderen ETL-Technik zu vergleichen, die änderungen seit dem letzten snapshot.
InformationsquelleAutor Cade Roux
1

Aufgrund der Art und Weise Triggern implementiert werden, in SQL Server alle Verstöße gegen die Vorgaben innerhalb der Trigger doom der Transaktionen.

Dies ist dasselbe wie:
```
DROP TABLE test

CREATE TABLE test 
(
        a INT NOT NULL
)

GO

SET XACT_ABORT ON
GO

BEGIN TRANSACTION

BEGIN TRY
        INSERT
        INTO    test
        SELECT  NULL
END TRY
BEGIN CATCH
        INSERT
        INTO    test
        SELECT  1
END CATCH
```
die Ergebnisse in einer dem Untergang geweihten Transaktion, außer dass es keine Möglichkeit zum deaktivieren XACT_ABORT in einem trigger.

SQL Server fehlt auch autonome Transaktionen.

Das ist ein weiterer Grund, warum sollten Sie alles, was Sie Logik in den gespeicherten Prozeduren eher als Trigger.
- eigentlich ist Sie nicht zum scheitern verurteilt Transaktionen, wenn Sie nicht mit try..catch.
- sicher, die Bedienung ist nur atomar aufgehoben. Das war nur um zu zeigen, was Los ist.
- Wie gespeicherte Prozeduren helfen? Ich dachte, wenn alles, was das auslösen würde, rufen Sie die gespeicherte Prozedur..., Um ein wenig hintergrund-info, was ich versuche zu erreichen hier: Wir haben einen Lieferanten geliefert ERP-system und möchten im live-up-to-date Daten aus Tabellen. Wir legen Trigger, um Ihre Tabellen, massieren Sie die Daten und kopieren Sie ihn auf unsere eigene Datenbank. Wir möchten Ihnen garantieren unseren Trigger wird nie Versagen, denn das würde zu Problemen führen, in der ursprünglichen ERP-system.
- Ich verstehe, und das wäre die beste Lösung in der Theorie. Aber die Trigger sind so umsetzen, wie Sie sind, und das bedeutet, dass ein Ausfall in einem auslösen, führen zu einem Fehler in der operation, abgefeuert. In der Regel ist dies umgangen, indem Sie eine gespeicherte Prozedur, die einen einzigen Zugangspunkt zu den Tischen. Dies ist jedoch nicht mit einer ERP system, das nicht unter Ihrer Kontrolle ist. Das beste, was Sie tun können, ist die Abfrage der ERP Tabellen direkt von Ihnen-Datenbank, verwenden Sie eine Replikation (die Einführung ein wenig Verzögerung) oder eine Kombination aus beiden verwenden die Auswirkungen zu minimieren und die lag.
InformationsquelleAutor Quassnoi
0
1. Sie sich wenden können XACT_ABORT off innerhalb der trigger (vorsichtig)
2. Können Sie die trigger eine gespeicherte Prozedur aufrufen. (Ich bin jetzt Ringen mit der entgegengesetzten problem: ich möchte die Transaktion abgebrochen, aber da die Logik ist in einem SP aus aufgerufen, die den trigger auslöst, und nicht der trigger selbst, dies ist nicht der Fall.)
InformationsquelleAutor Mark Sowul

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.