DB-Memofeld wer hats wann geändert

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