DB-Memofeld wer hats wann geändert

[jobo]

Meist kennt die DB aus der Situzung den Usernamen (und die Zeit sowieso).
Damit kann man per insert/ update trigger die Daten stempeln, am besten in separaten Feldern, die der User nicht ändern kann.
Ansonsten den Stempel in das Memo eintragen und bewachen, das der Inhalt vor Änderung erhalten bleibt, also nur Ergänzungen möglich sind.

[Aviator]

Zitat von jobo:

Ansonsten den Stempel in das Memo eintragen und bewachen, das der Inhalt vor Änderung erhalten bleibt, also nur Ergänzungen möglich sind.

Ein ähnliches Problem haben wir bei uns auch mit einer ganz eigenen Software. Daten sollen nicht gelöscht sondern nur neue hinzugefügt werden können. Aber was passiert wenn sich der Benutzer mal verschreibt und etwas korrigieren muss?

[jobo]

Naja, ist halt die Frage ob es einfach und schnell umgesetzt werden soll oder etwas programmieraufwand drin stecken darf.
Die einfache Lösung ist schlicht, auch die Korrekturen stumpf zu ergänzen. Clientseitig: Ein freies Memo, das den neuen Inhalt aufnimmt, vorm Post dann ans DB Memo plus UserZeitStempel dran hängt (oder an den Anfang).
Komplexere Dinge müsste man mit Änderungshistorie umsetzen, notfalls plus separate Felder alter Wert / neuer Wert.

[baumina]

Ja und wenn das Memo mal so lange geworden ist, dass der Ausdruck 3 Seiten Memo ausspuckt von Baugruppenänderungen, die 2003 mal gemacht wurden und wirklich niemanden mehr interessieren.

[baumina]

Was mir dank euch gerade so in den Sinn gekommen ist, ich könnte ja bei Modified des Memofeldes einfach den Benutzernamen und das Datum hinten ins Memo reinknallen.

[p80286]

Grauslich aber sollte ja Quickndirty sein

Gruß
K-H

[Der schöne Günther]

Oh, das hört sich ja exakt so an wie etwas das bei mir schon seit Monaten auf dem Tisch liegt. Die Motivation ist hier auch einmal feststellen zu können wer es war, aber noch viel eher dass die Daten nicht weg kommen können. Nicht dass ein Memo nur immer länger werden darf, sondern dass die alten Daten nicht weg sind.

Grade das wäre doch bei deinem "Memo-Suffix" nicht mehr gegeben, oder?

Meine Husch-Husch-Lösung wäre sich in ein "BevorNeueDatenAbgeschicktWerden"-Event einzuklinken und den aktuellen Datensatz (als dumme Textdatei) irgendwo zentral abzulegen. Die kann ja noch den eingeloggten Benutzer enthalten, Uhrzeit und aktuelles Wetter. So muss sich die Datenbank-Struktur nicht ändern und man kann im Notfall alte Daten wieder herstellen, den Schuldigen finden und wenn einem der Speicher ausgeht alle redundanten Kopien älter als X Jahre löschen. Lohnt sich natürlich nur wenn so etwas nicht zum Standardfall wird.

[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.