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?

hier was aus eknoris Schatzkiste: Änderungen am Dokument

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

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

doch, MIDAS kann das

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

@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

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 !)

@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 ;-)

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

Bernhard

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