Einfache Möglichkeit zur Aufzeichnung von Änderungen in Tabelle bei Posten

[AuronTLG]

Moin,

ich würde gerne für eine bestimmte Tabelle ein Änderungsprotokoll führen, d.h. für jedes Feld, dass beim Posten einen neuen Wert enthält, soll es einen entsprechenden lesbaren Eintrag in besagtem Protokoll geben.
Im Prinzip soll, nachdem auf einem Formular mit datenbanksensitiven Komponenten & DBNavigator, die über TFDTable/Query an der besagten Tabelle hängen, gepostet wird, eine Liste mit den Änderungen angelegt werden, die dann lesbar protokolliert werden können:

D.h. "XYZ klickt auf in einer Maske auf eine datenbanksensitive Checkbox und speichert" -> "XYZ hat ABC ein/ausgeschaltet" im Protokoll.
Oder "XYZ ändert Wert in DBEditSoundso von ABC auf DEF und speichert" -> "XYZ hat Wert Soundso von ABC auf DEF geändert" im Protokoll.

Der Rahmen, in dem dies passiert ist so überschaubar und simpel, dass eine einfache und unkomplizierte Lösung völlig ausreicht, d.h. die Felderanzahl ist überschaubar.
Die Vorschläge, die ich beim Suchen nach dem Thema gefunden habe, sind zumeist entweder veraltet oder zu komplex.

Mir fallen mehrere äußerst unelegante Brute-Force-Lösungen (OnChange, JvMemoryDatas etc) ein, zudem habe ich mir auch schonmal die FDEventAlert-Komponente angeschaut, aber mich würde mal interessieren, ob jemand eine simple Methodik dafür kennt.

[mkinzler]

Am Einfachsten über Datenbanktrigger oder der Monitoring-API von FireBird.

[peterbelow]

Das ist definitiv ein Job für Triggers in der Datenbank selbst (afterupate, afterinsert, afterdelete), sowas auf der Clientseite zu implementieren ist viel zu fehleranfällig und komplex, besonders bei Mehrbenutzersystemen.

Was Du allerdings noch zusätzlich brauchst ist ein Progrämmchen, das aus der von den Triggern erzeugten Audit-Tabelle einen hübschen Report für den Auditor erzeugt.

[hoika]

Hallo,
auch ich wäre für DB-Trigger.
Ein erster Ansatz wäre hier
https://www.ibexpert.net/ibe/pmwiki....birdReplicated

Zitat:

Die Vorschläge, die ich beim Suchen nach dem Thema gefunden habe, sind zumeist entweder veraltet oder zu komplex.

Welche sind denn zu komplex?

[jobo]

Also wenn von "Klicks" die Rede ist, lässt sich das mit DB Triggern nicht abdecken.
Kann FB "onSelect"?

Sobald Formularaktivitäten aufgezeichnet werden müssen, ist man vielleicht eher bei einem Webservice, der einfach alle Änderungen mitschreibt, Logtabelle geht natürlich auch.
Spannend wäre bei einer Clientlösung noch, dass man es ordentlich puffert, ggF. einen Effektivabgleich macht und die Aktionen in Summe erst wirklich protokolliert, wenn auch ein Commit erfolgt ist.
Manchmal ist der Teufel halt ein Eichhörnchen und aus einer "überschaubaren" Sache wird eine komplexe.

[mkinzler]

Zitat:

Also wenn von "Klicks" die Rede ist, lässt sich das mit DB Triggern nicht abdecken.
Kann FB "onSelect"?

Ich hatte ihn so verstanden, dass nur Änderungen an den daten protokolliert werden sollen.
Reine Abfragen kann nur über die Monitoring-API protokollieren. GUI-Aktionen natürlich nur in der GUI. Dafür gibt es aber ja asuch schon Lösungen (Analytics).

[Jasocul]

Grundsätzlich würde ich sowas über DB-Trigger lösen.
Wenn es aber in Delphi gelöst werden muss (aus welchem Grund auch immer), kann man im BeforePost NewValue und OldValue des DataSet vergleichen und daraus ein eigenes Protokoll basteln.

[mjustin]

Zitat von Jasocul:

Grundsätzlich würde ich sowas über DB-Trigger lösen.
Wenn es aber in Delphi gelöst werden muss (aus welchem Grund auch immer), kann man im BeforePost NewValue und OldValue des DataSet vergleichen und daraus ein eigenes Protokoll basteln.

Falls es beim Ausführen des Datenbank-Updates zu einem Fehler kommt, muss dies noch ins Protokoll (oder die bereits protokollierte Eintragung wieder gelöscht werden).