Persistente Doclinks seit R7

  • Einen schönen guten Abend miteinander,



    derzeit sitze ich vor einem kniffeligen Problem, das sich mir nicht recht erschließen will, nicht zuletzt auch, weil es in der Testumgebung nicht auftaucht und in der Produktion massiv für zerstörte Referenzen sorgte.


    Eine Dokumentenklasse "k" relationiert über Doclinks eine Dokumentenklasse "l" und "m".


    k:l ist wie 1:n (für n>=0)


    k:m ist wie 1:m (für m>0)


    Ändert sich nun in der Beziehung k:l die Anzahl der relationierten Dokumente, wird sinngemäß wie folgt verfahren:


    1.) Backend-Dokument des UIDoc holen: kDoc=UIDoc.Document


    2.) Das RichtextItem im kDoc über getItem holen und mittels Item.remove löschen.


    3.) Ein neues Richtextitem rtItem im k-Dokument erzeugen.


    4.) Aus den informell in einem Mehrfachwerte-Textfeld gespeicherten DocIDs das neue RichtextItem mittels rtItem.appendDoclink(lDoc,"") aufbauen.


    5.) Nach der Schleife über die Texteinträge: rtItem.update


    6.) saveoptions="0" im Backend-Dokument setzen.


    7.) Ein neues UIDoc im aktuellen Workspace mittels
    set UIDocNew=ws.editDocument(kdoc)
    erzeugen.


    8.) Das alte UIDoc schließen und vernichten: UIDoc.close() und Delete UIDoc.


    9.) Das neue UIDoc speichern.


    Das ganze funktioniert erstaunlicherweise sogar zunächst ganz gut, obwohl ich nie verstanden habe, wieso der Programmcode im alten UIDoc nach wie vor noch läuft, obwohl das alte UIDoc doch gerade gelöscht wurde. Ich hätte da spontan eine Schutzverletzung erwartet, aber es funktioniert und damit gut. :oops:


    Seit der R7-Umstellung nun haben wir das folgende Phänomen:


    In der ganzen Prozedur wird nur die k:l-Relation verändert. Die k:m-Relation wird nicht angefasst. Dennoch zeigt auf einmal nach dem Speichern das k:m auf eine ganz andere Dokumentenklasse als vorher, so als ob in dem k:m Richtextitem ganz andere Werte stehen würden.


    Dieser Effekt tritt sowohl unter R7.0.1FP1 als auch unter R7.0.2 auf.


    Gemeinerweise nur in der Produktion und nicht im Test. Die ganze "fixup, compact, updall"-Orgie ist selbstredend schon gelaufen. Auch ein Anlegen einer neuen Replik - sowohl über den Client als auch über den Server brachte keine Veränderung.


    Momentan behelfen wir uns damit, daß wir nach einer Veränderung jedweder Relationen in den Dokumenten ein "MachneueRelationen" aufrufen. Das ist allerdings ein starker Performance-Hit und nicht wirklich schön. Besser wäre es, wenn Notes die Relationen, die nicht berührt werden, gleich garnicht veränderte.


    Hat diesen Effekt schon mal jemand beobachtet? Wie habt Ihr das gelöst?



    Akane--

  • Zitat

    In der ganzen Prozedur wird nur die k:l-Relation verändert. Die k:m-Relation wird nicht angefasst. Dennoch zeigt auf einmal nach dem Speichern das k:m auf eine ganz andere Dokumentenklasse als vorher, so als ob in dem k:m Richtextitem ganz andere Werte stehen würden.


    Das gilt nach wie vor.


    Einen SPR, der mit diesem Phänomen zusammenhängen könnte, habe ich bei IBM gefunden:


    Code
    http://www-1.ibm.com/support/docview.wss?uid=swg27008587


    Dort ist unter der Nummer: JSHN6KPP8G


    (wörtlich zitiert ;-): "...Fixed problems which prevent link corruption...."


    Sonderbar nur, daß trotz der etwas unikaten Beschreibung des Fixes der Fehler sowohl mit 7.0.1FP1 als auch mit 7.0.2 auftritt und daß diese Regression mit der 6.5.5 implementiert wurde.


    Ist von dem Phänomen hier wirklich noch niemand gebissen worden?



    Akane--