Vielen Dank Joachim, fuer die ausfuehrliche Antwort. Kannst Du mir den T-SQL Befehl nennen, der in eine Textdatei schreibt? Irgendwie finde ich weder unter PRINT noch WRITE etwas in der Doku.
Th. -----Original Message----- From: Joachim van de Bruck [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 1:36 PM To: ASP Datenbankprogrammierung Subject: [aspdedatabase] AW: Ausgabe vom Trigger Hallo! > Ich bin's schon wieder. > > Ich brauche nochmal Eure Hilfe - diesmal mit einem Trigger, der nicht macht > was er machen soll. > > Gibt es irgendeine Moeglichkeit sich den Inhalt von INSERTED oder DELETED im > Browser (oder sonstwo) ausgeben zu lassen, wenn der Trigger getriggert wird? In "deleted" stehen alle Spalten der getriggerten Tabelle VOR der �nderung, also gel�schte Datens�tze und urspr�ngliche Werte bei �nderungen. Und in "inserted" stehen eingef�gte Datens�tze und neue Werte bei �nderungen. Allerdings gibt es keine BLOBs (text-, ntext-, image-Felder) in den Triggertabellen. Um diese tempor�ren Tabellen im Browser sichtbar zu machen, muss man die Datens�tze wieder in normale Tabellen einf�gen, die dann mit den entsprechenden ADO-Funktionen angezeigt werden k�nnen. Alternativ dazu gibt es M�glichkeiten in Transact-SQL, wie z. B. Speichern als Text- oder HTML- oder XML-Datei oder Versenden per E-Mail. Allerdings hat sich bei mir noch nie das Problem gestellt, Triggerdateien anzuzeigen. M�glicherweise hilft es, wenn Du Deine Trigger noch einmal analysierst: Gibt es vielleicht 2 oder noch mehr Trigger f�r eine Tabelle mit identischen Daten�nderungsereignissen? Diese m�ssten unabh�ngig voneinander ausgef�hrt werden k�nnen, da die Reihenfolge nicht festgelegt werden kann. Trigger 2 kann also vor Trigger 1 ausgef�hrt werden und deshalb nicht zwingend auf die Ergebnisse aus Trigger 1 zugreifen. Gibt es direkte oder indirekte Rekursionen? Trigger 1 �ndert die Tabelle 1 und l�st somit wieder ein Trigger-Ereignis aus, oder ein Trigger 1 zu Tabelle 1 �ndert Tabelle 2 und deren Trigger 2 �ndert wieder Tabelle 1 und l�st so erneut Trigger 1 aus - auch hier kann "Datensalat" entstehen. Um Konflikte mit Triggern zu vermeiden, kannst Du f�r die Trigger mit "IF UPDATE (Column)" oder "IF (COLUMNS_UPDATED())" die Triggeraktionen exakter differenzieren oder ganz brutal mit Systemprozeduren und -einstellungen die Trigger-Ausf�hrung beeinflussen. Ab SQL-Server 2000 kannst Du auch INSTEAD-OF-Trigger statt nur AFTER-Trigger einsetzen. Mein erster Fehler beim Umgang mit Triggern war die direkte Rekursion - Trigger �ndert Tabelle und l�st erneut einen Trigger aus. Das lag daran, dass ich den Trigger f�r Plausibilisierungen verwendet habe. Das ist unproblematisch, wenn es Bedingungen gibt, die Triggeraktionen nicht grunds�tzlich ausgef�hrt werden. Besser ist es jedoch, f�r Plausibilisierungen eigene Stored Procedures zu schreiben. Freundliche Gr��e Joachim van de Bruck | [aspdedatabase] als [EMAIL PROTECTED] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv Sie | k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.343 / Virus Database: 190 - Release Date: 3/22/2002 | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
