HCL Notes / Domino / Diverses > Entwicklung

Frage zu: Refresh von im Lesemodus geöffneten Dokumenten

(1/2) > >>

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:
--- Zitat ---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 ...
--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite