Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: Wiesel am 24.10.05 - 19:33:14
-
Hallo!
Ich meine es schon irgendwo gelesen zu haben, finde es aber leider nicht wieder.
Wie kann man einen mehrfachen Zugriff auf ein Dokument verhindern?
Ich habe eine Datenbank zur Termineintragung (pro Termin ein Kontrollkästchen) für eine kurzfristige Aktion in unserer Firma erstellt.
Auf die Datenbank haben ca. 800 Mitarbeiter zugriff. Es gibt insgesamt 8 Dokumente, in denen Termine festgelegt werden.
Wenn nun mehrere User gleichzeitig auf die Dokumente zugreifen, gibt es das bekannte Problem des Replizier- und Speicherungskonflikts. Und das möchte ich gerne verhindern.
Danke für Eure Tipps,
Wiesel
-
Uips, ich glaube, da ist das Konzept für die Applikation grundlegend verkehrt: 800 User auf 8 Dokumente loszulassen - das kann nicht gut gehen. Und (besonders unter R5) kannst Du den Zugriff auf Dokumente nicht wirksam sperren, da Du Dich in einer verteilten Umgebung bewegst.
Kannst Du genaueres zum Zweck der Applikation sagen ? Wege gibt es schon, aber dazu muss man mehr wissen ... Jegliches Locking kannst Du aber bei ernsthaftem Herangehen komplett vergessen.
Bernhard
-
Okay, näheres zu der Datenbank:
Es gibt 8 Masken (entsprechend der 8 Dokumente), da jede Maske für einen Tag steht.
Innerhalb dieses Tages gibt es dann jeweils vier Kontrollkästchen zu einer Uhrzeit.
Somit kann sich der User einen Tag aussuchen, innerhalb des Tages eine Uhrzeit und innerhalb der Uhrzeit gibt es vier "Plätze".
Wird ein "Platz" angeklickt, wird Username und OE gespeichert und ist dann nur noch für diesen User und für ausgewählte User mit einer bestimmten Rolle sichtbar. Somit ist keine Doppelbelegung möglich.
Mehr gibt es da schon gar nicht.
Kann man den Dokumenten nicht einen Flag im Postopen mitgeben? Und wenn ein weiterer User auf das Dokument zugreift und der Flag steht auf eins, kommt er nicht in das Dokument und bekommt eine Meldung. Wird das Dokument vom ersten User wieder gespeichert und geschlossen, wird der Flag wieder zurückgesetzt und das Dokument ist wieder "frei".
So hätte ich mir das vorgestellt.
-
Arbeiten denn alle auf dem gleichen Server ? Gibt es keine lokalen Repliken ? Haben alle Schreibrechte auf alle Dokumente ?
Dann könnte es klappen mit dem Flagsetzen im PostOpen. Das bedeutet dann aber auch, dass schon jedes Öffnen im EditMode zu einer Sperrung des Dokuments führt. Wann willst Du das Flag dann sicher (!) wieder entfernen ?
Eine MailIn-Lösung bei Änderungen würde mir sicherer erscheinen. Es gibt weitere Möglichkeiten, aber "simpel" sind sie alle nicht.
Warum prüfst Du aber unter den genannten Voraussetzungen nicht beim Speichern eines Dokumentes, ob diese Speicherung überhaupt zulässig ist ? Dann kann das Dokument frei von jeder Sperrung sein - wenn nicht möglich, kann eben nicht mehr gespeichert werden. Jedoch setzt auch dies voraus, dass es die DB nur genau einmal und nur auf einem Server gibt.
Bernhard
-
Die Datenbank ist nur einmal vorhanden.
Wie gehe ich denn dann so eine Prüfung der Zulässigkeit der Speicherung an?
Ansonsten hätte ich das Flag beim Speichern und Schließen des Dokumentes (über eine Schaltfläche) wieder entfernt.
-
Wie ist denn Deine Bedingung, dass jemand NICHT speichern darf ? Vermutlich, dass das entsprechende Kästchen, was er gerade angekreuzt ist (also im Backend gespeichert) mittlerweile bereits gesetzt ist. Du müsstest also im QuerySave den gerade aktuellen Zustand des Dokuments auf dem Server auslesen und mit dem Dokument des Users vergleichen. Ggf. musst Du dir im PostOpen noch den Zustand beim Öffnen merken, damit Du die ggf. entstandenen Unterschiede feststellst.
Hinweis: Das tatsächlich gespeicherte Dokument auf dem Server musst Du im QuerySave dann in einem gesondertem Objekt instantiieren - Dein Source.Document ist was anderes als das, was Du ggf. vom Server bekommst.
HTH,
Bernhard
-
Vielen Dank erstmal.
Probiere da morgen dann mal was aus.
Ansonsten melde ich mich wieder hier ;)
-
Hallo!
Ich habe ein ähnliches Problem mal mit einem sog. "In-Use-Dokument" gelöst, soll heißen, sobald das nicht parallel editierbare Dokument im Editiermodus geöffnet wird (QuerymodeChange), wurde im Backend ein weiteres Dokument, das "In-Use-Dokument", gespeichert. Es enthält einfach nur die Noteid des nicht parallel editierbaren Dokuments und vielleicht den Usernamen desjenigen, der das Dokument gerade in Beabeitung hat.
Das "In-Use-Dokument" wird automatisch gelöscht, sobald das nicht parallel editierbare Dokument geschlossen wird (Queryclose).
Wird nun das nicht parallel editierbare Dokument von weiteren Personen geöffnet, kann man hier unter Querymodechange in einer verborgenen Lookup-Ansicht, in der die "In-Use-Dokumente" angezeigt werden, nach einem "In-Use-Dokument" mit der gleichen Notesid suchen. Wurde ein entsprechendes "In-Use-Dokument" gefunden, wird der Wechsel in den Editiermodus unterbunden und eine Msgbox mit dem Hinweis, dass das Dokument von User xy z.Zt. editiert wird, angezeigt.
Klingt etwas umständlich, hat aber funktioniert, solange die Datenbank nicht auf mehere Server verteilt wurde.
-
Ich habe das Problem mit Hilfe folgender DInge gelöst:
http://news4notes.com/web/dokumente/notes_edit.html
Vielen Dank für Eure Hilfe!
-
Generell halte ich so ein Design für eher schlecht.
Besser: Beim Öffnen des Dokuments nur eine Kopie im UI öffnen (im queryopen) und beim Speichern dieser Kopie dann den Wert in das eigentliche Dokument schreiben - und anstatt zu speichern die Kopie verwerfen.
Damit werden dann Replizierkonflikte sehr sehr unwahrscheinlich - sofern nicht nichtgeclusterte Server verwendet werden (dann könnte man noch eine Dokumentebene für den Standort abstrahieren).
-
Ich habe das Problem mit Hilfe folgender DInge gelöst:
http://news4notes.com/web/dokumente/notes_edit.html
Vielen Dank für Eure Hilfe!
Das ALLEIN kann die Lösung des Problems ja nicht gewesen sein. Und ausführlicher ist das hier (http://atnotes.de/index.php?topic=20455.0) beschrieben. Was aber fehlt, sind die Abfragen Deiner Bedingung. Und sicher ist es natürlich immer noch nicht.
Was das "InUse-Dokument" betrifft, habe ich hier wie Gandhi tiefe Bedenken:
- Es werden bei jedem Öffnen bzw. Öffnen zum Editieren neue Dokumente in der DB erzeugt, die zumindest deletion stubs hinterlassen. Keine feine Art.
- Wenn der PC einfach ausgeschaltet wird oder Notes crasht (okay, sollte nicht passieren, aber ...), dann bleibt das Dokument erhalten. Und dann ist wieder Handarbeit angesagt.
- Es funktioniert - wie korrekt erwähnt - nicht über Repliken hinweg.
Bernhard
-
Nun, man könnte ja auf allen Repliken per Script das entsprechende Dokument locken.
Erst wenn auf allen Repliken das Schreibrecht bestätigt ist, kann man editieren - wobei elegant natürlich was anderes ist.
Was mir an der Lösung wirklich Bauchschmerzen machen würde ist, dass 100 Anwender auf 1 Dokument zugreifen sollen.
-
:-\
Och je, das war wirklich alles schmu.
Da denkt man sich was nettes aus und Notes macht es nicht so mit, wie man gedacht hat. Oder anders gesagt, es waren einfach zuviele...
Wir haben die ganze Idee nun verworfen und auf manuelle Eintragung von zwei ausgewählten Mitarbeitern gesetzt.
Vielen lieben Dank für Eure Hilfe.
Ich werde mir das bei Gelegenheit mal ganz in Ruhe durchlesen und mal ausprobieren. Wer weiß, wofür man es noch so brauchen wird...
Gruß,
Wiesel