Formelsprache Feld geändert von Änderungs Historie

[blattspinat]

Moin,

bin ein Frischling in der Notes Entwicklung und habe bei der Erstellung meiner ersten Datenbank ein Problem. Die Suche hat leider nichts 100 prozentiges geliefert, daher hoffe ich hier eine Lösung zu finden.

In einer Maske habe ich ein Feld erstellt, dass die letzten Änderungen enthalten soll. Ungefähr so:
Hans Müller am 01.01.2001
Peter Meier am 05.06.2010
Ich habe also ein Feld erstellt, dass Mehrfachwerte zulässt und berechnet wird. Außerdem habe ich folgende Formel hinterlegt:

Code

FIELD Autor:=Autor;

@If( !@IsNewDoc;
	@If( @IsDocBeingSaved;
		@Name([CN];@UserName)+" am "+@Text(@Today):Autor;
	Autor);
"")

Als Ausgabe erhalte ich leider immer sowas wie:
Hans Müller am Hans Müller am Hans Müller am Hans Müller am 06.07.2011
Jede Zeile kommt der Name einmal mehr vor.

Ich habe diese Lösung hier gefunden -> http://atnotes.de/index.php/topic,9486.0.html
Hier werden allerdings zwei Felder verwendet und ich möchte das ganze in nur 1 Feld haben.

Was mache ich falsch?

Danke im voraus, Gruß,
blattspinat

[Peter Klett]

(@Name([CN];@UserName)+" am "+@Text(@Today)):Autor;

[blattspinat]

Super! Vielen Dank! Hätte nicht gedacht, dass es so einfach ist

Problem gelöst!

[koehlerbv]

Für alle, die das später mal lesen:
Die Ausgangs-Fragestellung wird dadurch natürlich nicht beantwortet - wenn diese Formel in einem Feld steht, wird immer nur der letzte speichernde Bearbeiter verzeichnet.
Die eigentliche Forderung, x Änderungen zu dokumentieren, ist so natürlich nicht möglich.

Da ich Blattspinat (gerne!) esse, aber nicht als Dialogpartner akzeptiere, verzichte ich erstmal auf weitergehende Erläuterungen.

Bernhard

Tipp: Forumsregeln Punkt 2.2

[Peter Klett]

@Bernhard:

Da hast Du Dich verlesen. Das Feld heißt Autor und sein Inhalt wird bei jedem Speichern (sicherlich auch bei jedem F9) verlängert

(@Name([CN];@UserName)+" am "+@Text(@Today)):Autor;

[koehlerbv]

Mea culpa! Das war ein übler Überleser, insbesondere, wenn man im gleichen Atemzuge kritisiert.

Und mit Deiner Erklärung der fehlenden Klammerung bleibt der Thread ja auch lesenswert! Was Listenfelder und der Plus-Operator bewirken, ist zwar i nder Hilfe sehr gut erklärt - aber DIE Stelle muss man auch erstmal finden! Dass man da als Neuling daneben haut, ist völlig verständlich.
Auf der anderen Seite: Wenn man damit erstmal auf die Nase gefallen ist und die Erklärung gefunden oder hilfreich geliefert bekommt, dann hat man schon mal einen Eindruck, was man alles geniales mit Listenoperatoren in Notes anfangen kann 

Bernhard

PS: Sowie ich mich nicht mehr bei einem "Blattspinat" entschuldigen muss, tue ich das auch! Vielleicht erklärt das auch diese unsere Forumsregel 

[koehlerbv]

Noch zwei  Anmerkungen:
Bei F9 wird das Feld Autor nicht verändert, sondern nur beim Speichern (wegen @IsDocBeingSaved). Das passt also.

Weiters:
Es mag auf den ersten Blick abwegig aussehen, aber ich habe das schon weit mehr als einmal erlebt: Ein Textfeld ist endlich (nicht ganz 32 k an Zeichen, die jeweils zwei Byte belegen). Wenn jetzt einer sagt, dass das durch das Speichern niemals erreicht werden kann: Doch, das geht. Eher sehr, sehr selten, aber das geht (vor allem in Verbindung mit anderen Programmierfehlern).
Man sollte also auch an die Möglichkeit denken und abprüfen, ob ein neuer History-Eintrag überhaupt noch passt. In Formelsprache ist das nur eingeschränkt möglich (z.B. eine sinnhafte Anzahl von Elementen der History-Liste bestimmen und damit entscheiden) oder man macht es "perfekt" mit LotusScript.
Alternative: Wurde ein Dokument durch Überlauf eines Textfeldes "zerstört" und es lässt sich nicht mehr öffnen, dann braucht man gute Werkzeuge, um das Dokument zu retten.

HTH,
Bernhard (der wirklich gerne Spinat ist)

[Bruce Willis]

Wurde ein Dokument durch Überlauf eines Textfeldes "zerstört" ...

Kommt das wirklich vor? Was heißt bzw. inwiefern zerstört?
Wir sprechen hier doch von TF und keinen RTF.
Höchstens könnte ich mir im Feld eine Fehlermeldung vorstellen....

[Peter Klett]

Es geht um eine Historie in einem Textfeld, und die kann natürlich so groß werden, dass sie die maximale Feldgröße übersteigt. Und dann lässt sich das Dokument nicht mehr öffnen oder speichern.

[koehlerbv]

Leo, wenn Du die Fehlermeldung liest, ist es schon zu spät (unter gegebenen Umständen). Man kann auch noch was mit der IsSummary-Property drehen, aber ein derartiger Overflow wird für die Reparatur immer "tricky". Und das kann man ja bereits im Vorfeld vermeiden - besser ist das 

Bernhard

[Bruce Willis]

dann lässt sich das Dokument nicht mehr öffnen oder speichern.

Danke.
D.h. (zumindest für mich), das Dokument ist nicht zerstört sondern lässt sich nicht mehr normal bearbeiten.
In solchen Fällen könnte der Inhalt des Feldes per Agenten woanders kopiert oder das Feld bloß gelöscht werden.
Danach könnte das Dok wieder normal bearbeitet werden.
Und ob die History jemals wirklich so groß wird...

Kurz gesagt, ich finde Deinen Vorschlag für "die erste Datenbank" perfekt.
(@Name([CN];@UserName)+" am "+@Text(@Today)):Autor

Damit oder etwas Ähnlichem hat fast jeder von uns angefangen.

Gruß
Leo

[Bruce Willis]

das kann man ja bereits im Vorfeld vermeiden - besser ist das  

Bernhard, Du hast wie (fast) immer recht.  
Ein Formel-1-Pilot wird nie einen Opel Corsa fahren.
Aber ein Anfänger sollte lieber mit Corsa anfangen.
Kannst Du mir folgen?

Gruß
Leo

P.S. Kannst Du bitte einen Blick (nur bei Gelegenheit) auf den 3. Thread von oben werfen?

[koehlerbv]

Leo, Post #3 (! nicht Thread - das ganze hier ein Thread, einzelne Beiträge eben "Posts") ist mir sehr wohl bewusst und ich habe meinen Fehler beim Lesen des Codes bestätigt.

Und Formel-1-Fahrer pilotieren auch Autos in der Klasse des Opel Corsa. Aktuell: Fernando Alonso einen Fiat 500. Und warum auch nicht? Vettel hat noch keinen Punkt in Flensburg, "Oldie" Schumacher wurde in meiner Nachbarschaft in einem sehr normalen Auto geblitzt.

Worauf es mir aber ankommt: Der nächste baut trotz Warnungen und dem Dummspruch "Das kann ja gar nicht passieren!" den Code in einen Agenten ein ("DD.MM.YYYY Server: Dokument aktualisiert durch Agent")ein. Wenn der dann noch ... Na, das kann sich ja jeder ausmalen.

Bernhard

[Bruce Willis]

Leo, Post #3 (! nicht Thread - das ganze hier ein Thread, einzelne Beiträge eben "Posts") ist mir sehr wohl bewusst und ich habe meinen Fehler beim Lesen des Codes bestätigt.

Bernhard, Du irrst Dich leider wieder und wagst dazu noch MICH zu verbessern!!!  
Ich hatte NICHT Post #3 sondern Thread #3 gemeint.
Heute siehe unter #4
http://atnotes.de/index.php/topic,52096.0.html
Kuckst Du bitte an?

Worauf es mir aber ankommt: Der nächste baut trotz Warnungen und dem Dummspruch "Das kann ja gar nicht passieren!" den Code in einen Agenten ein ("DD.MM.YYYY Server: Dokument aktualisiert durch Agent")ein. Wenn der dann noch ... Na, das kann sich ja jeder ausmalen.

Deine Vorstellungskraft überschreitet alle Grenzen!  

Na gut, Du hast recht, bei einem täglichen Agenten sieht es ganz anders.
Wenn jemand aber "seine zweite Datenbank" entwickelt, kann man den oben vorgeschlagenen Code mit @Length und @Left so verbessern, dass die 32KB Grenze NIE (!) erreicht wird.

Was ist eigentlich Dein Vorschlag? RT-Feld verwenden?

Gruß
Leo

[Peter Klett]

Du hast zwar Bernhard gefragt, aber falls es Dich interessiert, wie ich das mache ...

Ich halte es für nicht ausreichend, zu wissen, wer das Dokument wann zuletzt geändert hat. Noch wichtiger zu wissen ist, was geändert wurde.

Daher ist ein neu erstelltes Dokument grundsätzlich ertmal im Entwurfsmodus. Meint der letzte Bearbeiter, dass es jetzt fertig sei, schließt er das Dokument ab. Erst dadurch erlangt das Dokument seine Gültigkeit und ist ab sofort nicht mehr änderbar. Soll der Inhalt des Dokuments geändert werden, erstellt man eine neue Version dieses Dokuments, das dann wiederum im Entwurfsmodus ist. Beim Abschluss der neuen Version wird der Vorgänger in seiner Gültigkeit begrenzt. Vorgänger und Nachfolger sind miteinander verlinkt, so dass man sich durch die gesamte Historie des Dokuments klicken kann. Ein Überlauf eines Historienfeldes ist damit ausgeschlossen.

Übertrieben? Beispiel Arbeitsanweisungen: Im Falle einer nachträglich Überprüfung durch eine Revision wäre es schon gut zu wissen, wie die Arbeitsanweisung zum Überprüfungszeitpunkt genau ausgesehen hat, und nicht nur, ob sie irgendwann in dem Zeitraum geändert wurde.

Das mag ein Exotenbeispiel sein, aber wenn man genauer nachdenkt, wird man viele Anwendungsmöglichkeiten finden. Wie wäre es mit einem Preiskatalog? Ist es nicht ggf. interessant zu wissen, welche Preise zu welchem Zeitpunkt gegolten haben?

Bei uns wird durchgängig so gearbeitet, daher vermisse ich solche Mimik z.B. auch im Names, z.B. bei Fehlersuche kann es schon hilfreich sein, zu wissen, welche Mitglieder eine Gruppe hatte. Oder es wird am Serverdokument etwas geändert und nach Wochen fällt auf, dass das Mist war. Wie es zuvor eingestellt war, findet sich dann vielleicht noch in der Datensicherung, da suchst Du aber wie ein Eichhörnchen.

Natürlich produzieren wir damit mehr Dokumente, als gewöhnlich. Daher ist eine saubere Skalierbarkeit der Anwendungen sehr wichtig. Dafür haben wir eine revisionssichere, lückenlose Dokumentation unserer Arbeit.

[klaussal]

Falls man keine Lust hat, selber etwas zu programmieren, gibt es für
solch eine Überwachung "SecurTrac" von Qkom.
http://www.qkom.de/ibmdomino/securtrac

[Bruce Willis]

Du hast zwar Bernhard gefragt, aber falls es Dich interessiert, wie ich das mache ...

Ja klar. Danke.

Ich halte es für nicht ausreichend, zu wissen, wer das Dokument wann zuletzt geändert hat. Noch wichtiger zu wissen ist, was geändert wurde.

Das stimmt. Scheint mir aber ein anderes Thema zu sein.
Ich hab sowas in einer DB mit dem Code realisiert, der mehrere Felder überwacht...

ein neu erstelltes Dokument grundsätzlich ertmal im Entwurfsmodus. Meint der letzte Bearbeiter, dass es jetzt fertig sei, schließt er das Dokument ab.  Soll der Inhalt des Dokuments geändert werden, erstellt man eine neue Version .... Ein Überlauf eines Historienfeldes ist damit ausgeschlossen.

Auch mit dem Text-Feld realisiert?
Und wenn das Dokument 3000 Mal - wie Bernhardt meint - bearbeitet wird?  

daher vermisse ich solche Mimik z.B. auch im Names, z.B. bei Fehlersuche kann es schon hilfreich sein, zu wissen, welche Mitglieder eine Gruppe hatte. Oder es wird am Serverdokument etwas geändert und nach Wochen fällt auf, dass das Mist war. Wie es zuvor eingestellt war, findet sich dann vielleicht noch in der Datensicherung, da suchst Du aber wie ein Eichhörnchen.

Ja, das stimmt.
Ich lege mir dafür per Batch die täglichen gezippten Backups von NAB auf meinem Rechner an.  
Seit etwa einem Jahr...
Hast Du vielleicht eine andere Lösung schon gefunden?

[Axel]

Falls man keine Lust hat, selber etwas zu programmieren, gibt es für
solch eine Überwachung "SecurTrac" von Qkom.

Oder man schaut sich das mal an:

http://atnotes.de/index.php?topic=18601.0

Axel