Dein Trigger krankt an einigen Problemen, die du vermutlich noch nicht siehst.
1) Inserted kann mehr als einen Datensatz beinhalten, wenn mehr als ein Datensatz vom INSERT, UPDATE oder DELETE betroffen ist. Bei
set @index = (SELECT idx_Filiale from inserted)
knallt es also, weil SELECT mehr als einen Wert liefert. Das gleiche gilt auch bei
BtoB_Filiale.Aenderung_Durch=(SELECT login_name FROM sys.dm_exec_sessions...
2) Selbst, wenn man das mit TOP 1 abfängt, könnte das von dir ungewollte Nebenwirkungen haben. Der Trigger feuert pro Statement einmal, nicht pro Datensatz, wie man das z.B. bei MySQL vorgeben kann. Man sollte also alles, was im Trigger passiert, immer so aufbauen, das es mehr als einen Datensatz verarbeiten kann. Auch wenn der User vor der Software vielleicht immer nur einen Datensatz gleichzeitig anfasst, kommt irgendwann der Punkt, wo mal Daten importiert oder exportiert werden, das sollte schon gehen.
3) Du aktualisierst immer den Datensatz in BtoB_Filiale für die Quelltabelle mit Benutzer und Zeitpunkt. Ja, das geht theoretisch. Aber sobald zwei Aktionen in der Tabelle, eventuell auf unterschiedlichen Datensätzen, hinter einander erfolgen, verlierst du alle Informationen über die Erste. Ich kann mir nicht vorstellen, das du das willst. Normalerweise schreibt man sich eher eine Log und erzeugt für jede Aktion einen neuen Log-Datensatz.
4) Ich verstehe nicht, warum du sys.dm_exec_sessions überhaupt abfragst. Das kann mehrere Probleme mit sich bringen, aber eigentlich brauchst du das gar nicht. SYSTEM_USER ist eine Variable, die dir immer zur Verfügung steht. Wenn du also als Benutzer SELECT SYSTEM_USER; aufrufst, bekommst du den aktuellen Benutzer angezeigt, mit dem du den Select ausgeführt hast. Ein Trigger läuft im Kontext des Benutzers, der die Aktion auf der Tabelle ausgelöst hat. Wenn also ein Trigger SYSTEM_USER abfragt und in eine Tabelle schreibt, dann ist das immer der Benutzer, der die Aktion auf der Tabelle gemacht hat. Eigentlich sollte das völlig ausreichen.
Ich schreibe dir mal einen Beispielcode. Ich kenne den Primary Key nicht und verwende pk als Spaltenname. In der Log-Tabelle setze ich mal noch zwei Spalten voraus: "fk_BtoB_Filiale" ist die ID des Datensatzes, der betroffen war und "aktion" das, was passiert ist. Das kann man theoretisch natürlich weg lassen aber irgendwie will man ja schon sehen, was genau passiert ist.
[CODE]
USE [Fahrwerk]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[Datum_Aenderung_Filiale]
ON [dbo].[BtoB_Filiale]
AFTER INSERT,UPDATE
AS
BEGIN
SET NOCOUNT ON;
INSERT INTO BtoB_Filiale(Letzte_Aenderung,Aenderung_Durch,fk_BtoB_Filiale,aktion)
SELECT getdate(),
SYSTEM_USER,
i.pk,
(CASE WHEN i.pk IS NOT NULL AND d.pk IS NULL THEN 'Insert' WHEN i.pk IS NOT NULL AND d.pk IS NOT NULL THEN 'Update' WHEN i.pk IS NULL THEN 'Delete' ELSE NULL END)
FROM INSERTED i
FULL OUTER JOIN DELETED d
ON i.pk = d.pk;
END
[/CODE]
