nicht angemeldet
Hi Ludger,
mit "Verhalten umgehen" meinte ich das Verhalten, was sich da beim Kollegen zeigt: dass nur ein Update in der Triggerausführung gemacht wird, obwohl er vielleicht mehrere Datensätze in der Tabelle [t] (seiner Ausgangstabelle, auf welcher der Trigger liegt) geändert hat.
Also:
UPDATE [t] SET [spalte1] = {irgendeine expression} WHERE {irgendeine expression} -- ändert in einem Rutsch vielleicht 1000 Datensätze
Der UPDATE Trigger wird aber nur einmal gefeuert, es wird (im Fall des Kollegen) nur einmal von [inserted] gelesen (nämlich der letzte Datensatz in [inserted] mit SELECT [spalte1] FROM [inserted] (das TOP 1 mal weggelassen)
[inserted] beinhaltet aber mehrere Datensätze. An all diese da drinnen kommst du nur mit einem Cursor über [inserted]. Innerhalb des Cursors mache ich ein Update auf [v] (eine weitere Tabelle, nicht die originale mit dem Trigger).
Ob er auf [v] einen Trigger hat, der wiederum [t] ändert weiß ich nicht. Wäre dann ein rekursives Trigger-Verhalten, was man für gewöhnlich meiden sollte (deaktivieren sollte).
Mir ist nur nicht ganze klar warum er SELECT TOP 1 [spalte1] FROM [inserted] benutzt - das ORDER BY nicht zu vergessen - da er damit von der ganzen Tabelle auch nur einen einzigen Datensatz bekommt, den ersten anhand einer spezifischen Sortierung eben.
... dieses Trigger-Problem ist recht weit verbreitet. :-)
Ciao, als denn
Frank