Vielen Dank für die zahlreichen Antworten. Leider haben wir noch V7R2 - knapp daneben.

Ich glaube ich werde wohl eine zentrale Tabelle basteln in der wichtige Programme ihre Aktionen protokollieren können, um somit dem Benutzer eine Art Verlauf in die Hand zu geben.

Ziel soll sein, dass der Benutzer sieht, wann, wer, etwas geändert hat.

Ich dachte an solch einen standardisierten / flexiblen Aufbau:
Code:
EventTable
-----------------
ID
SCHEMA
TABLENAME
ACTION
PROPERTY -- evtl. s. Kommentar unten
COLUMN -- evtl. s. Kommentar unten
VALUE
CHANGED
JOBUSER
Die Unterscheidung COLUMN u. PROPERTY habe ich deshalb vorgesehen, da der Feldname der Tabelle nicht zwangsläufig der Eigenschaft in der Klasse entsprechen muss.

Das soll dann weniger als Journal bzw. Restoremöglichkeit dienen, als viel mehr - ich wiederhole mich - dem Endanwender die Möglichkeit geben, eine Art Verlauf anzeigen zu können (wer hat wann was geändert).

Pro Tabelle immer Trigger anlegen etc. ist zwar sicherlich "sicherer" gegen Manipulation, mir geht's hier aber eher darum, dass ich ein standardisiertes Verfahren entwerfen kann um eine Art Log anlegen zu können.

Evtl. wäre es ratsam, ich speichere auch den Wert des Primärkeys der betroffenen Tabelle, sodass ich den Datensatz eindeutig identifizieren kann. Den alten Datensatz speichere ich dann komplett als XML-Objekt (C#) in der Spalte VALUE meiner Eventtabelle. Dann müsste ich nicht pro ColumnChanged einen Insert abfeuern (Speicherexplosion), allerdings würde dann das Log natürlich nicht nur die geänderten Eigenschaften anzeigen, sondern wirklich den kompletten Satz.

Haltet ihr so ein Konstrukt für gut/schlecht/gefährlich oder hat jemand eigene Erfahrungen in der Richtung?