DB-Memofeld wer hats wann geändert

[baumina]

Ich habe im Moment in meiner DB-Anwendung ein Memofeld, in dem jeder Benutzer Hinweise zu einer Baugruppe hinzufügen, ändern oder löschen darf. Nun kommt die Frage auf, wenn ein Benutzer weder sein Kürzel noch ein Datum dazuschreibt, weiß keiner mehr wer das wann eingetragen hat. Und wie es eben so nach ein paar Monaten ist, es will keiner gewesen sein.

Nun fragt mich mein Chef nach einer einfachen, schnellen Lösung um sehen zu können wer wann was in das Memofeld eingefügt/geändert oder gelöscht hat. Meiner DB-Anwendung ist der eingeloggte Benutzer bekannt. Aber wie es halt bei einem Memofeld so ist, es wird mal hier und da von einem Report gedruckt oder einer Maske angezeigt.

Mir fällt leider nichts "einfaches schnelles sinnvolles" dazu ein, euch vielleicht?

[Lemmy]

was für eine Datenbank? Wenn die Trigger unterstützt, kannst Du in einem BeforeUpdate Trigger eine Logtabelle schreiben, wenn sich der neue Inhalt vom alten Inhalt unterscheidet,

Grüße

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

Zitat von jobo (Beitrag 1330544)

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? :gruebel:

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

[p80286]

Ein "Update/Insert"-Trigger + LastEditor + LastEditDate ?

irgendwie den roten Kasten übersehen?

Gruß
K-H

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

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

Zitat von harfes (Beitrag 1330599)

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? :D

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. :P

[baumina]

Ein Inhalt meines Memofeldes sollte z.B. so aussehen:

Code:

Absplitterung vorne rechts. 10.01.2016 ABCFirma HMüller

Metallisierungsvorgang fehlerhaft. 12.01.2016 DEFFirma AScholz

Achtung: Baugruppe nur für Löttests verwenden 15.01.2016 MasterFirma RGutachter

Nach Rücksprache mit Herrn Walter soll diese Baugruppe für weitere Versuchszwecke eingesetzt werden. 20.01.2016 MasterFirma RGutachter

Irgendwann interessiert die Absplitterung vorne rechts nicht mehr, weil die Baugruppe für Löttests zersägt wurde, dann wird der Kommentar der Absplitterung und des fehlerhaften Metallisierungsvorgangs rausgelöscht.

Diese Arbeitsweise funktionierte nur so lange gut, als die Anzahl der Firmen und Benutzer überschaubar war. Nun vergessen viele Datum und Name zur Bemerkung zu schreiben.

[jobo]

Zitat:

Zitat von baumina (Beitrag 1330641)

Ein Inhalt meines Memofeldes sollte z.B. so aussehen:
..
Diese Arbeitsweise funktionierte nur so lange gut, als die Anzahl der Firmen und Benutzer überschaubar war. Nun vergessen viele Datum und Name zur Bemerkung zu schreiben.

In einem solchen Fall müssen ja auch alte Informationen gepflegt bzw. überarbeitet werden. Ein schnöder "Schreibschutz" für den alten Inhalt ist ja dann eher kontraproduktiv. Es ist eine bequeme Maßnahme, die aber den Nutzen des gesamten Mechnismus aushebelt und ihn damit wahrscheinlich noch mehr zum Streiobjekt macht.
Was also mit einem Zeit/Nutzerstempel erreicht werden sollte, wird mit der Form der Umsetzung wieder verhindert.

Ich würde eher versuchen, mir ein Ok für eine aufwändigere Lösung zu holen. Z.B. eine Lösung mit mehreren Datensätzen, wovon dann einzelne gelöscht werden können, wenn sie nicht mehr relevant sind. Änderungen oder Korrekturen könnte man durch Delete (alt)/Insert(geänderten Text) abbilden.

[rapante]

Zitat:

Zitat von baumina (Beitrag 1330641)

Ein Inhalt meines Memofeldes sollte z.B. so aussehen:

Code:

Absplitterung vorne rechts. 10.01.2016 ABCFirma HMüller

Metallisierungsvorgang fehlerhaft. 12.01.2016 DEFFirma AScholz

Achtung: Baugruppe nur für Löttests verwenden 15.01.2016 MasterFirma RGutachter

Nach Rücksprache mit Herrn Walter soll diese Baugruppe für weitere Versuchszwecke eingesetzt werden. 20.01.2016 MasterFirma RGutachter

Dafür scheint das Memo nicht die richtige Lösung zu sein...

Dann lieber einzelne DS, wobei du dann Zeitstempel und Benutzer selbst pro Eintrag setzen kannst.

[p80286]

@Baumina
das ist wieder die typische "Datastoring by Notizzettel Lösung".
warum nicht für eine Platine mehrere Memos mit Zeit und Benutzerstempel, die in der Anzeige zusammen geführt werden? (wie z.B. Einzeiler in einer Listbox) Überflüssige Informationen können dann immer noch gelöscht werden.
So wie Du es skizziert hast wird da nichts draus, da sich die wenigsten Benutzer an irgendwelche Vorgaben halten. "Man sieht doch was da steht" und dann versuch mal die Änderungen von Willi Müller am 02/02/1999 zu finden.

Gruß
K-H

[baumina]

Die komplexe "richtige" Lösung kenne ich und war auch mein erster Vorschlag, aber wie Chefs eben so sind, ich darf nur eine halbe Stunde Zeit reinstecken :roll:

[nahpets]

Dann würd' ich die alten Daten unverändert für immer drin lassen.

Das DB-Memo wird readonly.

Es gibt eine Edit für die Eingabe der Textzeile (sind ja wohl immer "Einzeiler".

Beim Speichern des Datensatzes wird dann eine neue Zeile ans Memo gehängt, die aus dem Inhalt des Edits + Datum + Benutzername besteht.

ungefähr sowas:

Delphi-Quellcode:

procedure TfmMain.qrySQLBeforePost(DataSet: TDataSet);
begin
  if edKommentar.Text <> '' then begin
    DBMemo.Lines.Add('');
    DBMemo.Lines.Add(Format('%s | %s | %s', [edKommentar.Text, DateTimeToStr(Now), Benutzername]));
  end;
end;

Gelöscht und geändert werden kann nicht mehr.
beim Anzeigen des Memoinhaltes direkt an das Ende des Memos gehen, dann sind die alten Daten halt "oben rausgeschoben".

Wie will man denn (ohne Historisierung) in 'ner halben Stunde sicherstellen, dass in einem Memo zu erkennen ist, dass es etwas nicht mehr (oder eine veränderte Fassung) gibt und von wem es entfernt (oder geändert) wurde?

Das geht doch nur, indem man es woanders hinschreibt - eben historisiert.

[OT]Befürchte das hier wieder ein leidiges Problem auftritt:

Die Suche nach einer einfachen und billigen Lösung und die Einigung auf deren Umsetzung, verbraucht mehr Zeit und Resourcen, als die sofortige Umsetzung einer vernünftigen Lösung.[/OT]

[p80286]

[OT]
wasch mich aber mach mich nicht nass
[/OT]

Unter den Umständen ist nahpets Vorschlag wahrscheinlich das beste was man bekommen kann.

Die genaue Syntax muß man/Du dann noch auskaspern.

Code:

update tablememo set mfeld=mfeld||chr(13)||chr(10)||'Meinewerte'||chr(9)||to_char(sysdate,'YYYYMMDD')||chr(9)||UID where id=12345;

Gruß
K-H

[baumina]

Manchmal werden auch ganze Mailtexte reinkopiert, ist halt ein Memofeld mit dem man tun und lassen kann was man will. *Schulterzuck* Eierlegende Wollmilchsäue lassen sich wirklich schlecht mit solch Sonderkomfort ausstatten, aber erklär das mal meinem Chef.

Ich fahr grad die Strategie ... nicht weiter drüber diskutieren ... abwarten, erledigt sich meist eh von selbst.

[BUG]

Zitat:

Zitat von p80286 (Beitrag 1330648)

das ist wieder die typische "Datastoring by Notizzettel Lösung".

Oder auch: Verstoß gegen die erste Normalform.

Zitat:

Zitat von baumina (Beitrag 1330649)

ich darf nur eine halbe Stunde Zeit reinstecken :roll:

Und dann bei jeden neuem Problem nochmal 2 Stunden :mrgreen:

[Jasocul]

Zitat:

Zitat von baumina (Beitrag 1330541)

Ich habe im Moment in meiner DB-Anwendung ein Memofeld, in dem jeder Benutzer Hinweise zu einer Baugruppe hinzufügen, ändern oder löschen darf. Nun kommt die Frage auf, wenn ein Benutzer weder sein Kürzel noch ein Datum dazuschreibt, weiß keiner mehr wer das wann eingetragen hat. Und wie es eben so nach ein paar Monaten ist, es will keiner gewesen sein.

Und was passiert, wenn einer die Einträge eines Anderen verändert?

Zitat:

Zitat von baumina (Beitrag 1330541)

Nun fragt mich mein Chef nach einer einfachen, schnellen Lösung um sehen zu können wer wann was in das Memofeld eingefügt/geändert oder gelöscht hat.

Das geht nur über eine Protokollierung. Dabei muss du den alten und den neuen Zustand festhalten. Zusätzlich (Anforderung des Chefs) Zeitpunkt und Name. Da würde ich mal nebenbei dezent auf den Datenschutz hinweisen wollen. In manchen Fällen ist sowas zulässig, aber oft bedenklich.

Zitat:

Zitat von baumina (Beitrag 1330541)

Meiner DB-Anwendung ist der eingeloggte Benutzer bekannt.

Deine DB kennt den Benutzer bestimmt auch. Ist also nicht von deiner Anwendung abhängig.
Wie die meisten, empfehle ich den Einsatz von Triggern. Dann wird auch protokolliert, wenn am Programm vorbei etwas mit den Daten gemacht werden sollte (Zum Beispiel der Admin direkt auf der Datenbank). Innerhalb des Programms kannst du auch im BeforePost etwas machen. Da du nicht wissen kannst, was geändert wurde, ist es völlig sinnlos den Text irgendwie auf Vollständigkeit zu parsen. Die Änderungen können ja auch mittendrin gemacht worden sein.

Zitat:

Zitat von baumina (Beitrag 1330541)

Aber wie es halt bei einem Memofeld so ist, es wird mal hier und da von einem Report gedruckt oder einer Maske angezeigt.

Was hat das mit dem Problem zu tun? Oder muss jeder zu jeder Zeit sehen können, wer was geändert hat? In dem Fall müsstest du noch eine Änderungs-Historie ins Programm einbauen. Einfacher geht es so: Jemandem fällt auf, dass Informationen falsch oder unvollständig sind --> Info an Chef, dass da was nicht stimmt. Der prüft dann die Historie und leitet alles weitere ein. Aber auch hier gilt: Datenschutz beachten.

Der Trigger ist in einer halben Stunde locker zu machen (wohl eher 10 nur Minuten, wenn man es schonmal gemacht hat). Eine Mini-Anwendung, die das Änderungs-Protokoll anzeigt, ist für dich sicher im Halbschlaf in 10 Minuten zusammengeklickt. Ist ja nur eine kleine Anzeige-Anwendung mit einem SQL.

[p80286]

Zitat:

Zitat von Jasocul (Beitrag 1330696)

Deine DB kennt den Benutzer bestimmt auch. Ist also nicht von deiner Anwendung abhängig.

Das ist aber nicht mehr "State of the Art". Moderne Anwendungen loggen sich nur auf einem Konto ein und geben dann eine UID mit.:evil:

Gruß
K-H

[Jasocul]

Ja und? Dann wird eben die UID analysiert. Über die lässt sich der Name auch feststellen.