Dokumenthistorie / Feldvergleich (vorher/nachher)

[TMC]

Ich habe hier eine kleine DB mit 1 Maske (6 Text- bzw. DateTime-Felder und 2 RT-Felder).

Ziel ist eine Dok-Historie, die z.B. wie folgt aussieht:

31.05.04  User 1    Feld "Datum" geändert (ex-Wert: 01.01.2000), Feld "Subject" geändert, ex-Wert: Hallo)
01.06.04  User 2    Feld "Body" (Richtext) geändert

a) normale Textfelder
Da habe ich mir überlegt, ich setze die paar (6) Werte der Felder jew. in eine globale Variable und vergleiche dann die Werte beim Speichern
b) Richtext
Hier würde (verständlicherweise) reichen, festzustellen, ob darin Änderungen vorgenommen wurden (ja/nein).
Gibt es da eine simple Möglichkeit, oder muss ich da z.B. mit @Abstract, etc., Ermittlung der Feldgröße u.v.m. arbeiten?

[TMC]

Da fällt mir gerade zu RT-Feld ein: Item LastModified property sollte hier schon genügen, schau ich mir mal an.....

[eknori]

hier was aus eknoris Schatzkiste: Änderungen am Dokument

[TMC]

Danke Ulrich für den Code, schau ich mir gleich mal an.

Mir ging es hier speziell um die Fragestellung, wie feststellen, ob RT-Feld sich geändert hat.

Habe gerade notesitem.LastModified erfolgreich getestet (Setzen in PostOpen und Vergleich im PostSave) - was wunderbar klappt.

[eknori]

da wirst du wohl letztendlich auf Kollegen Ben L.( http://www.geniisoft.com/) zurückgreifen müssen. In Script kannst du das nicht nachbilden und die 200.000 Zeilen Code von Midas muss man nicht unbedingt versuchen, in C nachzuplappern. Das ist und bleibt einfach ein geniales Teil und ist sein Geld 100 pro wert. Nicht für den privaten Einsatz, aber es gibt genug Unternahmen, die das nutzen...

[TMC]

Ulrich, mir ging es nur darum ob sich ein RT-Feld geändert hat (ja/nein), nicht was genau.
Und item.LastModified ist die Lösung hierzu. Klar, für alles weitere müsste ich z.B. Midas einsetzen.

[eknori]

ah, wer lesen kann, ist klar im Vorteil: dir geht es um das Datum der letzten Änderung; ok dann bist du bei notesItem.LastModified = The date that an item was last modified. bestens aufgehoben. Dachte, du wolltest die eigentlichen Änderungen protokollieren...  

[TMC]

Dachte, du wolltest die eigentlichen Änderungen protokollieren...  

Zum Glück ist das nicht die Aufgabenstellung. Man denke nur daran User ändert auf Zeile 723 lediglich im 3. Buchstaben vom 12. Wort die Schriftfarbe von lilablassblau auf rotviolett und ich soll das mitprotokollieren  
Spätestens dann setze ich einen Keylogger ein und importiere dann die Logs in Notes
  - oder setzeMidas ein (wobei ich mir das auch nicht wirklich einfach vorstelle damit).

[eknori]

doch, MIDAS kann das

( nein.. bin kein Vertriebspartner von Ben L.)

[koehlerbv]

Sischer, sischer - da bin ich auch fest davon überzeugt.
Aber grau ist alle Theorie: Ich stelle mir jetzt mal, wie die Änderungshistorie von TMC aussieht, wenn in einem RTF 'ne lange Doku geschrieben wurde. Nach dem Speichern kurzes Entsetzen - die Rechtschreibprüfung muss ja noch drübergejagt werden.
Der Feldvergleich mit Midas (hervorragendes Tool !!) liefert dann die zu dokumentierenden Änderungen ... Ein Textfeld für die Dokumenthistorie reicht dann nicht lange  

Bernhard

[koehlerbv]

@TMC:
Solch eine Dokumentenhistorie kann immer wieder gebraucht werden. Ich würde Dir aus eigener Erfahrung empfehlen, hierfür gleich allgemeingültige Routinen zu schreiben:
- In den Declarations ein Array mit den zu überwachenden Feldnamen (ein späteres Erweitern / Reduzieren ist so easy machbar)
- im PostOpen das Auslesen der Ist-Zustände in ein weiteres Array of Variants (wenn DataType = RICHTEXT, dann spezielles Verfahren)
- eine allgemeingültige Routine zum Vergleichen von Notes-Items (wenn DataType = RICHTEXT, dann spezielles Verfahren), der es egal sein muss, welcher Datentyp vorliegt oder ob EMPTY, Scalar oder Array
- eine History-Routine, die die ItemSize des History-Felds überwacht und dieses beschreibt.

Einmal gemacht, ist das dann vielseitig einsetzbar. Lohnt auch, nett in eine Klasse zu kapseln ;-)

Bernhard

[eknori]

>> Ein Textfeld

OK, I stimm u 2; aBär look at http://eknori.dyndns.org/knowledge/devidea.nsf/Alpha/0EB33C0ACD4A50248025681F002D517E?OpenDocument

welche Paranoiker sind denn da eigentlich am Werke ...

das sollte doch wohl alles im Rahmen bleiben (können)

[TMC]

Solch eine Dokumentenhistorie kann immer wieder gebraucht werden. Ich würde Dir aus eigener Erfahrung empfehlen, hierfür gleich allgemeingültige Routinen zu schreiben

Bernhard, Du kannst wohl Gedanken lesen, genau das hatte ich vor  

Die Historie selbst schreibe ich übrigens in ein Richtextfeld und nicht in ein Textfeld (mit NotesrichTextParagraphStyle und rt-Kollechen :-)), damit ich eine saubere Formatierung erhalte: http://www.atnotes.de/index.php?board=7;action=display;threadid=14772

Ich will im Prinzip als Endziel
a) eine (nahezu) Copy&Play fähige Lösung auch für andere DB's
b) Null Aufwand haben wenn sich Felder ändern, neu hinzukommen oder entfallen

Und Du hast ja hierzu schon die Vorgehensweise kurz beschrieben - sowas ähnliches hatte ich mir auch schon ausgedacht   (wenn auch noch nicht so detailliert - ist in jedem Fall ein guter Anhaltspunkt zum starten !)

[koehlerbv]

@Ulrich:
Jo, völlig wahr.
Es kommt immer auf die äusseren Umstände an. Nach denen müssen sich dann die technischen Massnahmen richten.
Meist reicht "fein und knackig"  

Bernhard

[koehlerbv]

@TMC:
Nö, Gedanken lesen kann ich nicht. Aber ich hatte eben auch schon die eine oder andere Erfahrung sammeln können bzw. müssen.

By the way: Gerade wegen der Allgemeingültigkeit und der Übersichtlichkeit habe ich mich gegen RTFs als History fields entschieden. Bei mir sind das Textlisten, die über eine Function belegt werden, der ich die Anzahl der erlaubten Einträge mitgebe (dass dabei die max. Grösse eines Textfelds nicht überschritten wird, dafür sorgt die Function selber). Das gibt mir später die Möglichkeit, applikationsspezifisch die History nach bestimmten Stichworten von oben oder von unten zu durchsuchen und darauf wiederum zu reagieren, ohne dabei gleich eine straff "mehrdimensionales" (also "mehrfeldige") History führen zu müssen.

Wenn natürlich jeder "Pups" von Anfang bis Ende protokolliert werden muss und es dabei egal ist, dass die eigentlichen Informationen 2 kB, die History aber 12 MB umfasst - dann muss es ein RTF sein. Ich wünsche Dir aber, dass Du solche Paranoiker nicht im Nacken hast ;-)

Bernhard

PS: Gerade letztens wünschte ein Kunde die History auf drei Einträge beschränkt zu bekommen. Das war dann sogar mir zuwenig, aber des Kunden Wunsch ist sein Himmelreich. Wenn er es sich anders überlegt, muss ich in den Funktionsaufrufen ja nur eine Zahl zu verändern. Und da das eine globale Konstante in diesem Falle ist ... Könnte man ja sogar ins globale Setup-Doc verlegen ;-)

[TMC]

BTW, habe ja oben geschrieben, die Historie schreibe ich in ein RT-Feld.
Problematisch sind da ja immer die berechneten Richtextfelder.
Ich hatte als kleine dezente Schriftart Arial, Größe 8 gewählt. Ist das RTF aber berechnet, dann klatscht es mir die Historie als Courier New mit Schriftgröße 10 (oder so) rein - auch wenn ich ein neues Doc erstelle.
Habe nun daher in meinem Historie-RTF folgenden Entering-Code:

Sub Entering(Source As Field)
   Dim ws As New NotesUIWorkspace
   Dim uidoc As NotesUIDocument
   Set uidoc = ws.CurrentDocument
   uidoc.GoToField( "Subject" )
End Sub

Ist nicht wirklich sauber, aber lt. ersten Tests sicher dass da niemand rumändern kann.

[koehlerbv]

Wie eben schon geschrieben: Bist Du Dir wirklich sicher, gebügend Gründe gesammelt zu haben, dass die History ein RTF sein muss ?

Bernhard

[TMC]

Aufgrund der Formatierungsmöglichkeiten (Tabs) und damit Übersichtlichkeit erstmal ja.

Wobei es da sicherlich auch Mittel und Wege mit Textfeldern gibt (z.B. die Historie on the fly [also z.B. per Buhtong-Klick] hübsch in einem RTF anzeigen zu lassen).

Wie auch immer - werde mir das noch genau überlegen.

[koehlerbv]

Das mit den Tabs ist aber ein dünnes Argument. Ich meine, ich will Dir ja nix ausreden, aber Tabs kannst Du genauso in normalen Textfeldern einsetzen (da müssen halt nur im History field selbst die Tabs definiert werden). Dazu sind dann die Chr$ (9) noch ein schönes Trennzeichen für weitere Auswertungen (wie vorher von mir schon erwähnt).

Sag' mal an, wie Du weitermachst - würde mich echt interessieren (checke ja auch dauernd mein handlen mit den Erfahrungen aus der Praxis ab).

Merci,
Bernhard

[TMC]

Bernhard, es ging mir nicht nur um Tabs (siehe auch Link oben auf den anderen Thread).

Wie kann ich z.B. sowas


mit normalen Textfeld(ern) machen? Die rechte Spalte kann da auch mehrere Einträge aufweisen. Zusätzlich will ich da auch fortlaufenden Text reinbringen, der einige Zeilen haben kann - und dies mit proportionaler Schriftart.
Ich sehe keine Möglichkeit ohne RTF, aber lasse mich gerne eines besseren belehren :-)