Set uidoc = uiws.EditDocument(True, doc) erzeugt Frage nach Erstellung eines Replizierkonflikts

    Hallo,


    ich wollte mal kurz nachfragen, ob folgends Szenario jemanden bekannt ist und wie man sich das erklären kann.


    Ich habe in einer DB (Domino 6.5.4) eine Maske A und eine Antwort Maske B.


    Jetzt gibt es eine Ansicht, wo Dokumente mit Maske A und die Antwortdokumente von B angezeigt werden. Nun soll es in der Anwendung so sein, dass wenn eine Antwortdokument (also Maske B) geöffnet werden soll, das korrespondierende Hauptdokument mit Maske A im Editmodus geöffnet werden soll.


    Soweit auch nicht das Problem, denn es gibt zum einen das $REF Feld und ich habe eindeutige Nummern, mit denen ich die Referenz herstelle.
    Jetzt aber zu dem Problem.


    In der Maske B habe ich folgenden Code im PostOpen Event:



    Das klappt auch soweit. Ich will ein Doc mit Maske B aufmachen, das zugehörige Dokument A wird geöffnet (im Editmodus) und B geschlossen.
    Wenn der Benutzer nun Dinge ändert und speichert, kommt die Meldung, dass eine Kopie des Dokuments gespeichert wurde, während ich es bearbeite. Und ich könnte ein Konfliktdokument erstellen.


    Das "Lustige" ist nun, wenn ich in folgender Zeile das True durch false ersetze (also nicht mehr im Edit Modus öffne), geht alles wunderbar.


    Zitat


    Set uidoc = uiws.EditDocument(False, doc)


    Ich lasse das jetzt erst mal so, muss der Benutzer halt auf Edit klicken. Nicht weiter schlimm, aber komisch finde ich das schon.
    Zumindest habe ich keine plausible Erklärung dafür.


    Vielleicht hat ja jemand eine Idee?

    Ne. Das QueryOpen ist leer. Da hatte ich den Code zuerst drin, weil ich mir dachte, bevor das auf ist wäre besser.
    Aber da kam ich via Source.FieldGetText nicht auf meine Nummer.


    Da kanns also nicht dran liegen.

    Wieso hast du dann nicht einfach auf Source.Document.FeldName(0) zugegriffen ?


    Bisher ist das bei mir immer nur aufgetreten wenn ich eben über ein Event (möglich wäre z.B. auch noch der Recalc Event) das andere Dokument verändert habe.


    Was du noch probieren könntest wäre das ganze nicht im Event der Maske B zu machen sondern direkt in der Ansicht im QueryOpenDocument. Damit kannst du dann auch gleich verhindern, daß das Antwortdokument geöffnet wird und musst es nicht erst schliessen

    Jetzt weiss ich es wieder, warum nicht QueryOpen:


    Denn das set uidoc = uiws.EditDocument(..) ist im QueryOpen einer Maske nicht erlaubt.


    Das mit der Ansicht finde ich ein wenig unschön, werds aber mal probieren. Denn dann müsste ich ja in jede Ansicht, wo die Dokumente angezeigt werden das Handling einbauen.


    Ich glaube, ich muss meine Maske A noch mal untersuchen. Gerade eben habe ich das nämlich mal in einer leeren DB mit genau den beiden Masken nachvollzogen und da kommt die Meldung nicht.


    In meiner Anwendung gibt es eigentlich nicht so viel Code in der Maske A. Okay, im QuerySave setze ich im UIDoc ein paar Feldwerte, aber das sollte ja nicht ausgeführt werden. Laut Debugger wird es das auch nicht. :-?


    Aber das hört sich schon danach an, als wenn da irgendwas schief laufen könnte.


    /EDIT:


    Gerade habe ich mal die QueryOpenDocument Sache implementiert. Hier passiert das gleiche. :-o

    Dem stimmt ich zu, dass meine Masken schuld sind. Ich werde mal suchen....


    Was mich halt wundert, was ist denn wohl der Unterschied zwischen dem uiws.editdocument(true, doc) und einem Doppelklick auf das Dokument der Maske A in der View und dann ein "Edit"?


    Denn wenn das "normal" geöffnet, bearbeitet und gespeichert wird, kommt der nette Hinweis nicht.

    So, jetzt ist die Verwirrung komplett.


    Ich habe mal alle Events der Maske A gelöscht und es kommt die Meldung immer noch. Vielleicht hat die Maske ja einen an der Klatsche..... :hammer:


    Setzen wir das Posting mal auf Closed.


    Danke auf jeden Fall für die Tips und Ideen.

    Nicht unbedingt die Maske, aber ich kann z.b. auch über ein berechnetes Feld Werte in einer anderen Maske setzen.
    Oder wenn du Teilmasken verwendest haben diese ebenfalls noch Evenets die das auslösen können

    Jo auch klar.


    Aber das Dingen ist fast so einfach, das man sagen könnte "Das progge ich mit verschlossenen Augen!" :D


    Maske A hat keine Teilmasken. Okay, eine eingebettete Ansicht, wo Dokumente der Masken C, D und E angezeigt werden. Dann noch ein wenig Skript, wo ich in globalen Variablen aktuelle Werte sichere und nach dem Speichern auf Veränderungen teste (Stichwort: Historie). Aber das hatte ich ja gelöscht.


    Maske B speichert nur "Systeminfos", die ich per Agent setze, da hat der User also keinen Einfluss drauf. Die einzigen berechneten Felder da drin sind Leser und Autorenfelder. Die Infos kommen zwar teilweise aus den Dokumenten der Maske A, aber ob das das Problem verursacht??

    Nur noch mal wenn einer eventuell über das gleiche "Problem" stolpern sollte.


    Es war das "Document locking", welches bei der Datenbank aktiviert war/ist. Augenscheinlich scheint da dann in der Tat der Adminserver im Background zu hantieren, damit die "$Writer" und "$WriterDate" Infos in das Dokument kommen. Aber augenscheinlich etwas zu langsame für das uiws.EditDocument(true, notesdocument).
    Denn sobald ich Document locking deaktiviere, gehts wieder.

    Natürlich arbeitet da der Admin Server im Hintergrund, und wenn die DB eben nicht auf diesem liegt kann es etwas dauern bis das Dokument freigegeben wird.


    Allerdings verhindert das eigentlich ein gleichzeitiges Bearbeiten und damit auch Speicherkonflikte

    Dass der Adminserver im Hintergrund arbeitet ist schon logisch.


    Man kann das Problem wirklich ganz leicht reproduzieren.
    - Eine Leere DB auf einen Server
    - Document Locking aktivieren (inkl. Adminserver)
    - Maske A erstellen und ein Dokument anlegen
    - Maske B als Response anlegen und ein Dokument erzeugen
    - Den Code ins PostOpen von Maske B (inkl. Anpassung des Formula-Strings)


    Wenn nun editdocument(true, notesdocument) drin steht, gibts einen Konflikt und wenn editdocument(false, notesdocument) drin steht, klappts auch ohne Konflikt.


    Ich hätte bei editdocument(true, ...) erwartet, dass hier genau das gleiche passiert, als wenn ich manuell das im Lesemodus geöffnete Dokument durch einen Doppelklick bearbeiten will.


    Aber lassen wir es gut sein. Das Problem ist ja gelöst. Ich wollte halt nur noch mal kurz des Rätselslösung darstellen.

    Also ich hab das grade mal aus Interesse nachgebaut, aber bei mir klappt das mit aktiviertem Document Locking und ohne Speicherkonflikte.


    Eventuell liegt es bei dir dann noch noch zusätzlich an etwas anderem und das Document Locking ist nur ein Faktor

    Hi,


    gibts doch gar nicht.
    Ich habe jetzt mal einen anderen Dominoserver genommen und da bekomme ich auch die Konfliktmeldung.


    Ohne Document Locking alles wunderbar.


    Welche Versionen hat Dein Dominoserver?
    Ich habe das auf einem 6.5.4 und einem 6.5.4FP2 HF462 getestet.


    Komisch...

    Hallo,


    hat hier zufällig noch jemand einen Dominoserver 6.5.4?
    Denn gerade habe ich das auch mal auf einem 7.0.2 ausprobiert und siehe da, kein Problem mit EditDocument(TRUE).


    Das hört sich ja fast nach einem Bug in 6.5.4 an ....


    Es wäre super, wenn das jemand auf 6.5.4 nachstellen könnte.

    Ich hatte dasselbe Problem.
    Server: 6.5.5
    Client: 6.5.6


    Ähnliche Ausgangslage: ich erstellte im Backend ein Dokument und öffnete es schlussendlich im Frontend. Mit Dokument-Locking bekam ich beim zweiten Speichern die Meldung des Konfliktes.


    Die Analyse des Problems ergab, dass beim QuerySave das Dokument noch nicht gelockt ist, im PostSave dann schon. Da ich das Dokument im Backend erstellte lief der erste Save sauber durch, nach dem Save (zwischen Query- und PostSave) lockte er dann das Dokument (im Backend), was dann zum Konflikt führte.


    Sobald das UIDokument dann geschlossen wurde und erneut geöffnet funktioniert alles korrekt, das Problem trat "nur" beim ersten Öffnen auf.


    Mögliche Lösung:
    Im QuerySave die Felder $Writers und $WritersDate manuell setzen:

    Code
    Dim ses As New NotesSession
Call Source.Document.ReplaceItemValue("$Writers",ses.UserName)
Call Source.Document.ReplaceItemValue("$WritersDate", Now)
Call Source.Reload()