SQL Server 2008 R2 - Change Data Capture / Trigger alternative

[palaber]

Hallo zusammen,

ich suche eine passende alternative zu Change Data Capture (CDC) oder Triggern für eine SQL Server 2008 R2 Datenbank.
Ich möchte, dass Änderungen automatisch mit geloggt werden. Nicht nur wo und welche Spalte geändert wurde, sondern auch den "alten Wert" einer Zelle.

Eigentlich würde sich hierzu ja CDC anbieten, allerdings wird dies von der Express Version nicht unterstützt... Trigger sind nur zweite Wahl, da ich nicht jedes mal, wenn ich an einer Tabelle etwas ändere ich den Trigger / die Zieltabelle ändern möchte.
Gibt es noch eine Möglichkeit, Änderungen/Neuerungen abzuspeichern?

 

[rIQ]

über eine stored procedure?

welche die vorigen Werte in einer History-Tabelle versioniert und neue einpflegt

 

[DanielBm]

über eine stored procedure?

welche die vorigen Werte in einer History-Tabelle versioniert und neue einpflegt

Das Problem ist, dass auch die Stored Procedure ja irgendwie getriggert werden muss.
Außerdem muss man sich ja irgendwie den Zustand vor der Änderung abspeichern.

Ich denke du wirst an Triggern nicht vorbeikommen (es sei denn, du willst in irgendeiner Art das Transaktionsprotokoll auslesen á la 'dbcc log' oder so, was ich nicht empfehlen würde). Ein reines mitloggen der Änderungen sollte von der Performance her nicht das Problem sein, da du ja keine aufwendigen Berechnungen machen musst.

 

[palaber]

Genau, die Performance ist nicht das Problem. Nur die Tatsache, das zu den getriggerten Tabellen immer wieder
neue Spalten hinzugefügt werden. Somit muss ich ja den Trigger auch anpassen. Das wollte ich umgehen.
Na, dann wird es mir wenigstens nicht langweilig

 

[DanielBm]

Naja, du könntest versuchen, dir die Spalteninfos aus der master-db rauszuziehen.
Da hast du ja alle Informationen drin.

Und dann könntest du dir (wahrscheinlich nur über dynamisches SQL) das ganze zeilenbasiert in eine Tabelle speichern mit evtl. folgendem Aufbau:
Tabellenname / Spaltenname / Wert vorher / Wert nachher / Operation / Zeitstempel / Benutzer ...

Irgendwie so in der Art, habe aber leider im Moment keine Zeit so etwas selbst mal auszuprobieren.

 

[rIQ]

Das Problem ist, dass auch die Stored Procedure ja irgendwie getriggert werden muss.
Außerdem muss man sich ja irgendwie den Zustand vor der Änderung abspeichern.

Ich denke du wirst an Triggern nicht vorbeikommen (es sei denn, du willst in irgendeiner Art das Transaktionsprotokoll auslesen á la 'dbcc log' oder so, was ich nicht empfehlen würde). Ein reines mitloggen der Änderungen sollte von der Performance her nicht das Problem sein, da du ja keine aufwendigen Berechnungen machen musst.

Ich meinte, das "insert-statement" durch einen "stored-procedure" Aufruf ersetzen.
D.h. du übergibst der proc deine Werte.

Dann benötigst du keine Trigger.