Auch wenn es technisch möglich wäre, ist es wirklich keine gute Idee! Ein Trigger sollte sehr schlank sein und auf keinen Fall eine langwierige Operation beinhalten (was ein Webservice-Aufruf definitiv ist)! Überdenken Sie Ihre Architektur – es sollte einen besseren Weg geben, dies zu tun!
Meine Empfehlung wäre, die Aufgabe des "Bemerkens", dass Sie den Webservice aufrufen müssen, in Ihrem Trigger von der tatsächlichen Ausführung dieses Webservice-Aufrufs zu trennen.
Etwas wie:
-
Fügen Sie in Ihrem Triggercode ein "do call the webservice later" in eine Tabelle ein (nur
INSERTum es schlank und schnell zu halten - das ist alles) -
über einen asynchronen Dienst (einen SQL-Job oder vorzugsweise einen Windows NT-Dienst) verfügen, der diese Aufrufe getrennt von der eigentlichen Triggerausführung durchführt und alle von diesem Webdienst abgerufenen Daten in den entsprechenden Tabellen Ihrer Datenbank speichert.
Ein Trigger ist eine sehr knifflige Sache - er sollte immer sehr schnell und sehr schlank sein - machen Sie ein INSERT oder höchstens zwei - und vermeiden Sie auf jeden Fall Cursor in Triggern oder andere langwierige Operationen (wie einen Webdienstaufruf)
Brent Ozar hat einen großartigen Webcast (vorgestellt bei SQL PASS) über Die 10 häufigsten Entwicklerfehler, die sich nicht skalieren lassen und Trigger sind das erste, worauf er seinen Fokus legt! Sehr zu empfehlen
