DB-Memofeld wer hats wann geändert

[p80286]

Halte ich für nicht so optimal.
Wenn Du DB-Inhalte als Datei irgendwo ablegst, kommt irgendwer bestimmt auf die Idee mal aufzuräumen oder der gegenteilige Fall, die irgendwo-Dateien überleben Deine DB um Jahre, weil man da nicht dran darf.
da schon lieber eine Tabelle AltMemos oder in der Memotabelle ein Feld mit der zugehörigen SatzID und eine Tabelle AktuelleSatzMemoVerknüpfung.

Gruß
K-H

[rapante]

Ich habe das bei mir für eine MultiUser Kalender-Anwendung ebenfalls über einen DB-Trigger gelöst der bei Änderung den kompletten Datensatz in eine History-Tabelle kopiert.

table_x
Felder: id, .., createuser, createdate, changeuser, changedate;
table_x_history:
Felder: id,id_table_x .., createuser, createdate, changeuser, changedate;

So kann ich jede Änderung einem User zuordnen und keiner kann sich rausreden

[stahli]

Würde es ähnlich wie rapante angehen.

Mehrere Memos als Detailtabelle mit Zeitstempel und UserNamen.
Der Admin darf alte Einträge löschen.

[jobo]

@Memo stempeln
Das wäre m.E. die billigste Lösung:
über Trigger am allerbilligsten, hier kann auch dafür gesorgt werden, dass nur Erweiterungen erlaubt sind.
über Delphi Code per ReadOnly DB Memo und einem nicht gebundenen Memo für die Ergänzung.

[baumina]

Danke für die Ideen, "perfekt" ist das alles nicht, aber es ist halt wie bei so vielen Dingen, die eierlegende Wollmilchsau, die zudem auch keine Arbeit machen darf, gibt's halt nicht.

[harfes]

Die Lösung von rapante setze ich seit Jahren in verschiedenen Projekten ein - sehr schnell umgesetzt und es ist über die Jahre alles nachvollziehbar. Der Admin (und nur der!) hat Vollzugriff auf die Historie-Tabelle auch vom Programm aus (ok, das ist ein klein wenig Mehraufwand für das zusätzlich Fenster).

Das ist zwar nicht super elegant aber erfüllt seinen Zweck und bei den heutigen DB's und billigem Plattenplatz kein Problem. Quick aber - wie ich finde - nicht dirty!

Hartmut

[madas]

Zitat von harfes:

Die Lösung von rapante setze ich seit Jahren in verschiedenen Projekten ein - sehr schnell umgesetzt und es ist über die Jahre alles nachvollziehbar. Der Admin (und nur der!) hat Vollzugriff auf die Historie-Tabelle auch vom Programm aus (ok, das ist ein klein wenig Mehraufwand für das zusätzlich Fenster).

Das ist zwar nicht super elegant aber erfüllt seinen Zweck und bei den heutigen DB's und billigem Plattenplatz kein Problem. Quick aber - wie ich finde - nicht dirty!

Hartmut

Wie elegant willst Du es denn noch haben?

Genauso machen wir das auch. Über History-Tabellen die via Trigger beim Löschen des Datensatzes oder Update eines oder mehrer Felder
(Update = Feldinhaltänderung bzw. neuer Feldinhalt ist leer, alter nicht bzw. alter Feldinhalt ist leer, neuer nicht) befüllt werden.
Die aktuelle Benutzer-ID ist dem Programm bekannt und wird daher in einer PrepareSave Methode dem Datensatz vor dem Abspeichern in die
DB hinzugefügt. Der SQL-Quelltext für den (die) Trigger wird von der DB-Klasse (sie kennt ja alle Felder) generiert und beim Überprüfen
des DB-Schemas bei Programmstart hinzugefügt bzw. geändert, falls Felder hinzugekommen sind.

Das Löschen- bzw. Ändern-Dürfen wird per Benutzer- bzw. Rechteverwaltung gelöst.

Ist meiner Meinung elegant genug.