Seltsames Verhalten: Items verschwinden beim Speichern

[Tode]

Ich kopiere mit Code gewählte Dokumente aus Datenbank 1 (dbSource) in Datenbank 2 (dbTarget). Diesen Code verwende ich schon seit Jahren in meiner Toolbar, um Dokumente aus Rücksicherungen zurückzukoppieren, aber in einer Umgebung kopiert der nur ca. 8.700 con 9.100 Dokumenten.
Dabei behalte ich die Universalid des Dokumentes bei.

Der Code:

Code

Set docTarget = New NotesDocument( dbTarget )
docTarget.Universalid = doc.Universalid	
Call doc.Copyallitems(docTarget, True)
Call docTarget.Save( True, True, True)

Im Debugger sieht man, dass nach CopyAllItems alle Items im Zieldokument vorhanden sind.
Nach docTarget.Save ist das Dokument aber plötzlich wieder leer: Keinerlei Items mehr drin...

Sowas habe ich noch nie gesehen...
Bei den Dokumenten handelt es sich -scheinbar- um normale Mails: Keine Leserfelder, keine Verschlüsselung, keine signierten Items, kein MIME, kein $KeepPrivate...

Hat irgendjemand eine Idee, woran sowas liegen könnte?

[Werner Götz]

Passiert das nur bei einem bestimmten Dokument?
Was passiert, wenn Du die UniversalID nicht setzt?

-Werner

[Tode]

Es passiert -wie gesagt- bei 400 von 9.100 Dokumenten. Ich habe Tests mit einem Dokument gemacht, und ohne das setzen der UNID war es danach da... das ist aber für einen Synchronisationslauf etwas ungeschickt, wenn ich danach keinen "Unique identifier" mehr habe... Und das war auch nur ein Frontend- Lauf am Client...
Ich habe in einem anderen Versuch in einem Agenten das über GetDocumentByUnid() gefundene "No- Item- Dokument" gelöscht und nochmal neu gemacht: Danach erneut mit demselben Code angelegt: hat geklappt... Das Dokument war danach gültig.
Als ich diesen Code aber in einen Serverbasierten Agenten gepackt habe (selber Signer), dann ging das "reparieren" so plötzlich wieder nicht mehr...

Sehr seltsam das Ganze...

Wir haben jetzt rausgefunden: Die meisten Dokumente, die nicht kopiert werden können, produzieren ein "Element des Dokuments nicht gefunden" in der Statuszeile, wenn man sie im Client öffnet... Werde in dieser Hinsicht mal recherchieren: Optisch sehen die Dokumente normal aus...

[Werner Götz]

Ich würde mal vermuten, dass die UNIDs irgendwie und warum auch immer "geblockt" sind.

Um das zu verifizieren:
Was passiert wenn Du die Wiederherstellung in eine andere / neue Datenbank machst?
Funktioniert es dann bei allen?

-Werner

[Tode]

Wir haben 3 verschiedene Zieldatenbanken probiert: Immer die selben Dokumente fehlen... auch bei komplett neuen Zieldatenbanken...

[Werner Götz]

Ok, dann liegt es also an den Dokumenten selbst.
Wenn Du beim Wiederherstellen die UniversalID nicht änderst sind ja alle Items da.
Machen diese Dokumente dann en Problem beim Öffnen?

[Tode]

Ich lasse mir grade mal ein paar Beispiel- Dokumente zusenden, und dann werde ich all diese Tests machen können:

- Kopieren ohne UNID- Änderung, dann Vergleich der Items
- Kopieren mit UNID
- Statt CopyAllItems ein Forall item in doc.items

Dann melde ich mich wieder.
Danke fürs mitdenken!

[Tode]

Ich habe jetzt eine selektive Replik mit 18 Dokumenten, die sich in der Zielumgebung nicht kopieren lassen: Das Problem lässt sich bei mir mit selbem Code nicht reproduzieren...

Ich habe jetzt remote

- den Code auf doc.CopyToDatabase umgestellt und die UNID in Ruhe gelassen
- geprüft ob irgendwo ein Leserfeld oder Autorenfeld ist
- alle Items durchlaufen

u.v.m.

Ich gebe auf: ich finde keine Lösung... Inzwischen habe ich einen richtig geilen Zustand:

In einer weiteren Quelldatenbank mit dem selben Problem sind 21.000 Dokumente, die Zieldatenbank hat nur 20.500 Dokumente laut Datenbank- Eigenschaften.

Jetzt kommt der Hammer: Wenn ich mit einer Schleife prüfen will, WELCHE Dokumente in der Zieldatenbank fehlen, dann findet der Code keines:

Code

Set dc = dbSource.AllDocuments
'dc.Count = 21.000
'dbTarget.AllDocuments.Count = 20.500
Set doc = dc.GetFirstDocument
While not doc is Nothing
    On Error Goto ErrorUnid
    Set docTarget = dbTarget.GetDocumentByUnid( doc.Universalid )
    On Error Goto ErrorRoutine
    i = i + 1
    Set doc = dc.GetNextDocument(doc)
Wend
'i = 21.000
ErrorUnid:
 Print doc.UniversalID
 Resume Next

Dieser Code printet NICHTS...
Dann habe ich in beiden Datenbanken eine Ansicht gemacht: Nicht hierarchisch, nur 1 Spalte, @Text( @DocumentUnique ) und das Ergebnis in Excel verglichen.
Wie zu erwarten findet die SVERWEIS- Funktion von Excel 500 #NV- Werte, also die Differenz aus 21.000 - 20.500

Dann im Admin- Client in der dbTarget nach der UNID gesucht, die dort laut Excel fehlt (also nicht in der Ansicht): Ich bekomme ein gültiges Dokument mit allen Feldern...
Dann ein Set doc = dbTarget.GetDocumentByUnid( "UNID AUS EXCEL" ): Auch hier bekomme ich ein Dokument... ABER: Es ist nicht im Dokumentencount der Datenbank und auch nicht in der Ansicht...

Ich habe keine Ahnung was vorgeht, habe aber den Code zum kopieren der Dokumente in einen neuen Agenten neu geschrieben (selben Funktionen, selbe Vorgehensweise), und was soll ich sagen: Der neue Code funktioniert...
Keine Ahnung warum, weil im Kern genau das gleiche passiert... Whatever...

[Werner Götz]

Wenn die Dokumente da sind, aber nicht in Ansichten angezeigt werden, könnten diese ggf. als Designelemente angesehen werden. Kannst Du mal in Deiner Ansicht mit $FormulaClass "spielen" und alles mögliche anzeigen?

Siehe z. B. http://ozinisle.blogspot.com/2011/01/view-all-design-elements-in-lotus-notes.html

Warum aber ein anderer Agent mit exakt gleichem Code nicht dasselbe Ergebnis bringt ist natürlich schon sehr merkwürdig.
Das müsste dann ja daran liegen, dass ein neues Kompilieren einen abweichenden Code erzeugt.
Kann es sein, dass der fehlerhafte Agent schon vor ewig langer Zeit mit einer sehr alten Notes-Version kompiliert wurde?

-Werner

[Tode]

An "Designelemente" hatte ich auch schonmal gedacht... ich habe in meinen Datenbanken immer eine "DesignElements"- Ansicht drin... für diesen Fall ist mir das jetzt zu aufwändig... der neue Code funktioniert in allen getesteten Fällen, und reicht mir erst mal.
Der "alte" Code wurde zwar schon vor längerem geschrieben, aber erst vor kurzem komplett überarbeitet, sogar die Script- Library ist neu... das kann es also auch nicht sein... Wie auch immer... Danke für Deine Mithilfe. Da ich das Problem nur in der Kundenumgebung nachstellen kann, kann ich auch nicht beliebig experimentieren... ich schliesse das hier mal ab.