Frage zu: Refresh von im Lesemodus geöffneten Dokumenten

[FrankLU]

Hallo Notes-Gemeinde,

in einer Frage vom August 2021 https://atnotes.de/index.php/topic,63318.msg403702.html geht es um die Frage, wie man verhindern kann, dass ein Dokument, das in zwei Clients gleichzeitig zum Lesen geöffnet wurde, im ersten Client geändert und gespeichert wurde und danach im zweiten in den Edit-Modus gebracht wird, wobei natürlich die Änderungen vom ersten Client auf der Strecke bleiben.

Als Lösung wird vorgeschlagen:

Bevor dein 2. Client in den Editmodus wechselt führt er die von dir gewünschte Prüfung des in-memory-docs gegen das im Backend gespeicherte Dokument durch. Sollte das Dokument im Backend einen höheren Sequence-Zähler aufweisen erscheint die Meldung ...

Frage: Wie prüfe ich denn den Sequenz-Zähler? Welche LS-Befehle bzw. Felder muss ich da verwenden?

Grüße aus dem Pfälzer Glutofen
Frank

[jBubbleBoy]

Die DB-Eigenschaft "Sperren von Dokumente zulassen" macht doch alles notwendige.

[FrankLU]

Diese Option ist bei uns nicht praktikabel, weil viele Leute aus dem Homeoffice und in anderen Zeitzonen arbeiten. Und wenn dann ein User ein Dokument offen hat und dann das Internet weg ist, kommt niemand an das Dokument ran. Da wir einen 24/7-Betrieb haben, habe ich keine Lust, nachts um 3 Uhr angerufen zu werden, weil ein Dokument gesperrt ist, das aber dringend gebraucht wird.

[CarstenH]

Das sollte auch ohne Dokumentsperre funktionieren, da jeder Client beim Versuch zu speichern seinen Zähler gegen das Backend prüft.

Hat in deinem beschriebenen Szenario zwischenzeitlich jemand anders gespeichert ist der eigene Zähler niedriger und es kommt die berühmte Meldung am Client (Bild 1). Drückt der Nutzer auf Ja wird ein Konfliktdokument erstellt, drückt er auf Nein, passiert gar nichts

Er kann also gar nicht speichern und die Änderungen der anderen Person überschreiben, weder mit Ja noch mit Nein.

Die Vorgehensweise ist nun wie folgt:
- wenn Ja (Konfliktdokument) -> Vergleiche Konfliktdokument mit Original, führe beide Änderungen manuell zusammen, lösche Konflikt. Nichts ist verloren gegangen.

- wenn Nein -> Öffne Original und ändere erneut, optional kannst du deine Änderungen sogar aus dem noch geöffneten ungespeicherten Fenster mit Copy&Paste übernehmen und schließe dann das nicht mehr benötigte Fenster ohne speichern. Speichere nun das Original, das jetzt alle Änderungen beider Nutzer enthält.

Egal wie man es durchführt: es gibt eigentlich kein Szenario, bei dem die Änderungen der ersten Person verloren gehen können. Selbst wenn beide Nutzer auf unterschiedlichen Repliken arbeiten verlagert sich nur die Konflikterzeugung vom Client-UI auf den Replikator und die manuelle Lösung kann ebenfalls im Nachgang stattfinden - wieder ohne Datenverlust.

Sollte also derzeit tatsächlich ein Datenverlust stattfinden dann, weil ein Programmierer entweder eine Default-Einstellung geändert hat (man kann z.B. in der Maske die Konflikterzeugung tatsächlich deaktivieren mit der Gefahr von Verlusten eben) oder ein Agent im Hintergrund Änderungen vornimmt ohne mögliche Konfliktdokumente zu berücksichtigen. In jedem Fall klingt das dann nach einem "hausgemachten" Problem, das jemand untersuchen sollte statt einen vorhandenen funktionierenden Mechanismus (Sequenzzähler prüfen) abzuschalten oder nachzubilden.

HTH
Carsten

[FrankLU]

Hallo Carsten,

danke, dass Du Dir so viel Zeit nimmst für meine Anfrage.

Du hast ja mit allem Recht, aber in der Praxis arbeitet der Benutzer eben nicht so, wie man sich als ITler das so vorstellt und wünscht.

In der Anwendung sollen Ärzte Diagnosen, Anamnesen, Beurteilungen und Maßnahmen in Krankenberichte eintragen. Leider zählen Ärzte nicht unbedingt zu den IT-affinen Personen. Die nervt es schon, dass sie überhaupt etwas selber in Maskenfelder eintragen müssen. Daher werden sie bei einem zu speichernden Dokument immer auf "Konfliktdokument erstellen" klicken, einfach weil sie keinen Bock haben, planvoll vorzugehen, ihre Eingaben z.B. im Editor zu sichern und erneut in eine Maske einzugeben oder reinzukopieren. EDV hat bei denen so zu funktionieren, wie sie sich das vorstellen, dass sie funktionieren soll.

Und dann habe ich die Arbeit und darf die Konfliktdokumente bereinigen. Dazu habe ich nun wieder keine Lust.

Jedes Öffnen eines Dokument erzeugt ein Sperrdokument in einer eigenen Sperrdokumente-DB. Bei jedem Öffnen (zum Lesen) wird geprüft, ob für ein Dokument schon ein Sperrdokument existiert. Wenn ja, gibt's eine Meldung und das Dokument geht nicht auf. Dass mit dem Sperrdokumenten schreiben bzw. abfragen klappt aber nicht zu 100%, warum auch immer. Vielleicht sind die Ansicht der SperrDokumente nicht immer aktuell, vielleicht was anderes. Alle Benutzer arbeiten auf dem selben Server, da kann es keine Zeitverzögerungen durch Replizierung geben. Darum möchte ich gerne eine zweite Prüf-Instanz, die vor dem Umschalten in den Edit-Modus prüft, ob eine Dokument in der Zeit zwischen dem Öffnen zum Lesen beim Client und dem Umschalten in den Bearbeitungsmodus verändert wurde.

Du erwähnst wiederholt einen "Zähler". Wo finde ich den bzw. wie kann ich den abfragen? Ich wollte nichts anderes wissen. Ich finde in NotesDocument keine entsprechende Property.

Grüße
Frank

[CarstenH]

Hallo Frank,

da ich auch mit Ärzten zu tun habe weiß ich wovon du sprichst - allerdings sind Sachbearbeitende (hach, gendern ist toll...) da auch nicht besser. Sie haben nur nicht so viel Selbstbewusstsein "über" wie Ärzte. Aber das ist ein anderes Thema.

Ich kürze meine Kritik mal etwas ab indem ich die ketzerische Frage in den Raum stelle, was jetzt bei deinen Sperrdokumenten besser läuft als bei den Dokumentsperren, die dir Notes bereits von Hause aus bietet. Wenn ich da lese dass erst (per Script) auf Vorhandensein geprüft wird, Views nicht aktuell sind und überhaupt nicht immer alles wie es soll klappt. Beim integrierten Sperrmechanismus hast du nur ein Problem, wenn die Sperre mal nicht freigegeben wird und das löst bei mir ein periodischer Agent, der im Hintergrund alle Sperren freigibt, die älter als x Minuten sind. Im offenen Dokument läuft bei Bedarf ein Timer, der die Sperre einmal alle x-1 Minuten erneuert. Das ginge auch im Lesemodus übrigens. Aber okay, lassen wir das. Du hast dich entschieden und möchtest nur die nötigen Infos. Hier kommen sie:

Bild 1 zeigt dir die Sequence Number (SN) eines Dokuments. Ist unschwer zu erkennen hexadezimal dargestellt und erhöht sich mit jedem Speichern um 1.

Bild 2 zeigt dir die Sequence Number (Seq.-Num.) eines Feldes. Damit es nicht langweilig wird diesmal aber dezimal dargestellt. Diese erhöht sich beim Speichern nur, wenn das Feld ändernd angefasst, also der Inhalt neu geschrieben wurde, unabhängig davon ob sich auch wirklich der Wert geändert hat. Durch Vergleich der Dokument-SN und der SN jedes Feldes kann man herausfinden ob (und ggf was) geändert wurde.

Programmatisch gibt es mit LS keinen direkten Weg auf diese Infos zuzugreifen. Am einfachsten klappt es noch, wenn du schaust, ob das Feld $Revisions vorhanden ist und wieviele Einträge es hat. Unterscheidet sich der letzte Wert im Frontend vom letzten Wert im Backend weißt du, dass sich etwas geändert hat. Achtung: bei Konflikten oder Antwortdokumenten, die beim Speichern automatisch erzeugt werden kann das in die Hose gehen, da es dann mehr als ein Dokument im Backend gibt und die SN (bzw. $Revisions) dir dann nicht weiterhilft.

Willst du es genauer brauchst du die C-API: NSFDbGetNoteInfo oder NSFDbGetNoteInfoByUNID liefern dir die Daten.

Möchtest du dich ausführlicher mit ID's, Sequence Numbers & Co. beschäftigen habe ich bei Rudi noch eine Ytria Perle von Ben Benesi mit dem Titel Dissecting IBM Notes Documents: Hidden Secrets and Tricks Unveiled zum Selbststudium gefunden:
https://officecamp.de/konferenz/ent2017.nsf/bc36cf8d512621e0c1256f870073e627/5e0a00f1f3ef1bf3c125800e0043a8eb/$FILE/T2S6-Dissecting-Documents.pdf

Übrigens: zum schnellen Suchen/Lösen von Replizierkonflikten empfehle ich die (kostenlose!) Advanced Property Box von Panagenda. Die zeigt dir farblich an, was sich zwischen zwei Dokumenten unterscheidet und lässt dich das bei Bedarf auch gleich (ohne Maske) direkt im Dokument ändern. Da macht Konflikte Lösen fast schon wieder Spaß (Ein paar Kritikpunkte hätte daran aber dennoch - das ist aber ein wieder anderes Thema).

HTH
Carsten

[FrankLU]

Hallo Carsten!

Bitte entschuldige, dass ich Dir erst jetzt antworten kann. Urlaub und wiedrige Umstände haben mich davon abgehalten.

Danke für Deine Ausführungen und die Zeit, die Du Dir dafür genommen hast. Ich werde es mir zu Gemüte führen.

Grüße
Frank