[gelöst] 75% der Dokumente verschwinden Mysteriös...

[koehlerbv]

Mats schreibt doch, dass er nach dem Restore der DB eine neue ReplicaID vergibt, Andreas.
Ausserdem würde bei der Replizierung in den Lösch-Aktivitäten eher nicht der Name des Benutzers stehen.

Bernhard

[MatsBS]

I GOT IT!!!!

Ich habe jetzt mühsam herausgefunden, dass alle Deletion-Stubs in der names.nsf des Users verfügbar sind.

Wenn die MailDatenbank dann auf den Cluster repliziert wird und der User das erste Mal seine lokalen Kontakte mit dem Mailfile repliziert, so werden auch die Deletionstubs wieder ins Mailfile genommen und voilà, die Dokumente sind wieder weg!

[pram]

Was bitte hat die names.nsf damit zu tun?  ... aber da war was:
Wir haben uns letztens aber auch schon gewundert, dass im Traveler die lokalen Kontakte synchronisiert werden. Scheinbar macht Notes hier auf der Replikatorseite eine Replizierung der Kontakt-Dokumente zwischen lokaler names.nsf <-> mail-DB.

Interessant wäre aber, wieso kommen die deletion-stubs da überhaupt rein? (evtl doch durch das mobile Endgerät angelegt)

Gruß
Roland

[MatsBS]

Nein, es ist eigentlich jetzt im Nachhinein logisch wieso die da drinne stehen:

Über die Option "Synchronize Contacts" im pers. Adressbuch habe ich ja die Möglichkeit, meine Adressen auch aufs Mailfile zu "replizieren". Dies, damit ich im iNotes meine Kontaktdaten verfügbar habe.

Wenn ich nun im iNotes einen Kontakt löschen (dies passiert ja in meiner Maildatenbank), muss dieser deletionstub beim nächsten Replizieren natürlich auch ins names.nsf übertragen werden. Da in einer Deletion-Stub nur die UNID und ein paar Daten stehen, kann er natürlich nicht unterscheiden, bei welcher Deletion-Stub es sich um einen Kontakt oder z.B. um ein Memo handelt. Darum werden gleich alles Deletion-Stubs ins names.nsf übertragen.......!!!

Wenn ich jetzt also meine restorte DB wieder an die Stelle setze, wo das names.nsf das nächste Mal seine "Kontakte" und eben auch Deletionstubs hinrepliziert, dann ists passiert!

[omega]

Vielleicht steht ich ja auf dem Schlauch, aber wie löst man das nun am besten ?

[MatsBS]

...ja, das ist leider nicht so einfach.

Ich habs jetzt in dem speziellen Fall mal so gemacht, dass ich alle DeletionStubs aus names.nsf gelöscht habe.
Muss halt jetzt schauen, dass der User nicht plötzlich "gelöschte" Dokumente wieder in der DB hat...! Sehe sonst aber keine Lösung.

[notesbaby]

Hallo!

Ich weiß - Du hast "Thema gelöst" gepostet - aber hat sich hier nochmal was getan?

Grüße!

[koehlerbv]

Was sollte sich hier noch tun, Petra? Das funktioniert nun wirklich, wie man es auch logisch erwarten kann.

Unterbricht man den normalen Prozess (der "Replizierung" - wobei das in Wirklichkeit keine echte Replizierung ist!), dann muss man eben manuell nachhelfen, zum Beispiel mit entsprechenden Tools die Deletion Stubs in der Ausgangs-DB "meucheln", bevor wieder eine Synchronisation stattfindet.

Bernhard

[Tode]

Ich schätze, dass hier eine Archivierung zieht... und zwar auf einem ganz anderen Client....

Ich hatte das mal, dass ein Client eines Admins immer wieder die Datenbank eines Users bei sich lokal archiviert hat...

Ursache: Im persönlichen Adressbuch des verursachenden Benutzers (also desjenigen, der in den Datenbankaktivitäten als der drinsteht, der gelöscht hat), gibt es in der versteckten Ansicht "($Programs)" ein Programmdokument für compact -a Server!!mail\DeinUser.nsf

Wie das dahin gekommen ist, weiss ich nicht...

Deshalb auch das "unregelmässige"... wann immer DIESER Client gestartet wird (eventuell benutzt der User ja zu Hause einen anderen Client, oder aber es handelt sich um einen Admin- Client, der nur selten benutzt wird), fängt der an, die "Fremde" Maildatenbank zu archivieren. Checked mal darauf das ganze ab...

HTH
Tode

EDIT: uuups... vergesst es, hatte das hier gepostet, bevor ich die zweite Seite mit dem "gelöst" gelesen habe... Schande über mich...