Was kann dazu führen, dass Profildokumente gelöscht werden

[Christian Weiß]

In einer mehrsprachigen Datenbank, sind Profildokumente für verschiedene Sprachen angelegt worden.
Dies funktioniert auch alles sehr gut.
Leider ist es jetzt vorgekommen, dass Profildokumente plötzlich nicht vorhanden gewesen sind.
Absichtlich, zum Beispiel durch einen Agenten, ist dies nicht passiert.

Habt Ihr Ideen, was mögliche Ursachen sein könnten?

[koehlerbv]

Bei den vorliegenden Informationen bräuchte man eine Kristallkugel, um eine Antwort zu finden.

Abgesehen davon: Für die permanente Ablage von Informationen verwende ich aus den verschiedensten Gründen niemals ProfileDocuments, sondern immer "normale". ProfileDocuments sind dafür gedacht, Daten abzuspeichern, die man sinnvoll im jeweils lokalen Cache schnell zur Verfügung zu haben. Mehrbenutzerbetrieb, Replikation etc. sind schon Themen, die sich da mit "Daten im lokalen Cache" beissen.

Bernhard

[pram]

Wenn man eine neue Replik erstellt und diese sofort öffnet bevor das Profil repliziert wurde (und beim Öffnen gleich ein getProfileDocument ausgeführt wird) wird in der Replik ein neues leeres Profil angelegt und anschließend zurückrepliziert. Das neueste Profil gewinnt.
Wenn man das Profil dann löscht (und die DB bzw. den Notesclient neu startet) ist das alte wieder da...


Gruß
Roland

[Christian Weiß]

Ich versuche jetzt noch ein paar mehr Informationen zu geben.

Die Profildokumente für die Sprachen werden wie folgt erstellt:
Die Werte sind alle in einer Exceltabelle gespeichert. Für jede Sprache gibt es eine Spalte. In der ersten Spalte der Tabelle steht der Schlüssel. Skizziert sieht das dann z. B. so aus:

Key	DE-DE	EN-US
hRedExclamationMark	Das rote Ausrufezeichen zeigt an, dass dieses Feld vor dem Speichern des Dokuments ausgefüllt werden muss.	The red exclamation point indicates that this field must be filled before saving the document.

Mit Lotusscript wird diese Exceltabelle ausgelesen und die Werte werden dann in Profildokumente geschrieben. Für jede Sprache gibt es ein Profildokument. Für die ganze Oberfläche der Notes-Datenbank wird dann auf diese Profildokumente zugegriffen. Die Anwender haben die Möglichkeit Ihre bevorzugte Sprache zu wählen. Daher ist es hier sinnvoll gewesen mit Profildokumenten zu arbeiten. Ich habe auch gelesen, dass es in früheren Notes-Versionen wirklich noch Probleme mit Profildokumenten gegeben hat, aber inzwischen hat sich da viel getan.
Besteht denn die Gefahr, dass es wirklich zu Problemen bei der Replikation kommen kann?

[m3]

Au ja. Believe me.

[Christian Weiß]

Au ja. Believe me.

Kannst Du dazu mehr sagen?
Ich bin dankbar für jeden Hinweis.

[m3]

Ja.

Wir haben Stunden/Personentage damit verbracht, unsere Anwendungen wieder hinzubiegen, weil die Admins eine neue Replik auf irgendeinem Server erstellt & aufgemacht haben, bevor die Profildokumente dort waren. Damit haben sie neue Profildokumente erstellt, die wiederum fröhlich auf alle Server repliziert haben, wodurch in unseren Apps NICHTS mehr ging.

Profildokumente in mehreren Datenbanken über 3 Notes Cluster in 2 Notes-Domänen und in Summe etwa 10 Maschinen wieder auf EINEN Stand zu bekommen ist NICHT lustig.

[Christian Weiß]

Vielen Dank für die Information.

weil die Admins eine neue Replik auf irgendeinem Server erstellt & aufgemacht haben, bevor die Profildokumente dort waren. Damit haben sie neue Profildokumente erstellt

Dies ist mir noch nicht ganz klar. Wie sind die Profildokumente erstellt worden?

[TRO]

Schnipsel aus der Designer-Hilfe:

=======
Set notesDocument = notesDatabase.GetProfileDocument( profilename$ [, uniqueKey$ ] )
--> Retrieves or creates a Profile document.
=======

ergo: wenn ProfileDoc noch nicht hineinrepliziert dann wird ein neues, leeres ProfDoc angelegt und dass beisst sich dann mit dem später per Replikation eintrudelnden "richtigen" ProfileDoc.

hth

Thomas

[Thomas Schulte]

Es gab mal eine Variante mit der man Profildokumente sehr zuverlässig zum Verschwinden gebracht hat. Involviert war Lotus Script und ein CopyAllItems von einem Profildokument in ein anderes neues Profil Dokument. Danach war das Profildokument (laut Notes Peek) zwar noch da, aber nicht mehr ansprechbar. Irgendwie hab ich damals rausgefunden, das es wohl an der Kopiererei der $ Items gelegen hat ...

[ata]

@Roland

... Das neueste Profil gewinnt.
Wenn man das Profil dann löscht (und die DB bzw. den Notesclient neu startet) ist das alte wieder da...

... nach meiner Erfahrung ist das nicht so. Es heißt in der Dokumentation zwar, daß es keine Replizierkonflikte geben kann, fakt ist aber, daß es die dann doch gibt. Ich habe mir dafür ein Tool gebaut, mit dem ich die Replizierkonflikte der Profildokumente erkennbar und damit löschbar machen kann. In solchen Fällen zieht eines der Profildokumente - welches ist offen. Wenn also rätselhaftes Verhalten von Profildokumenten vorliegt, dann kann das eine Ursache sein.

Ansonsten versuche ich aus den oben genannten Gründen so gut wie möglich auf Profildokumente zu verzichten...

Toni

[pram]

ergo: wenn ProfileDoc noch nicht hineinrepliziert dann wird ein neues, leeres ProfDoc angelegt und dass beisst sich dann mit dem später per Replikation eintrudelnden "richtigen" ProfileDoc.

ACK,
wobei aber beim Replizieren kein Replizierkonflikt auftritt, da ja beide Dokumente eine unterschiedliche UNID haben.
(Ein Replizierkonflikt bei Profilen kann nur entstehen wenn sie die gleiche UNID haben)

Meines Wissens "erkennt" Notes ein ProfileDoc anhand eines speziellen "$Name" Items wie Thomas schon geschrieben hat.
Gibt es nun 2 Dokumente die wegen des $Name-Items als Profil klassifiziert sind so "gewinnt" das zuletzt gespeicherte. Sucht man in NotesPeek dann z.B. nach Dokumenten mit $Name="...." so findet man die alten (verdeckten) Profile wieder.


Gruß
Roland

[ata]

... ich hatte in der Vergangenheit wie gesagt echte Replizierkonflikte auf Profildokumenten - der letzte gewinnt nicht unbedingt - erkennbar am $REF-Feld...

Toni