"ReplikationskonfliktvermeidungsStrategie" ???

[dh-paule]

Hallo,

nun ist es soweit, meine 2.te grosse DB steht unseren Usern im FirmenNetz zur Verfügung. Während bei der ersten DB relativ klar war wer welches Dokument wann bearbeiten kann, ist es nun so das ca. 100 Aussendienstler auf eine DB oder deren lokale Replik zugreifen. Dabei wird es jetzt sicherlich vorkommen das das ein oder andere Dokument von mehreren Useren zeitgleich lokal bearbeitet wird. Was geschieht dann bei der Replikation?

Was passiert wenn ein user längere Zeit nicht repliziert und sagen wir mal die letzten 2 Änderungen eines Dok.s nicht bekommen hat und nun dieses Dok. repliziert nachdem er es auch geändert hat?

Wie kann ich dadurch entstehende Probleme abfangen?  

[koehlerbv]

Oh ja, das wird wieder ein interessanter und lehrreicher Thread ... Bei dem aber DAS Kochrezept nicht herauskommen kann, da hier das "Prinzip Notes" immer wieder auf andere Situationen stossen wird.

Ich fange mal an, meinen Senf dazuzugeben;
1. In den Maskeneigenschaften einstellen "Replizierkonflikte mischen". Wenn dann User A die Telefonnummer ändert und User B die Postleitzahl, dann kommt es zu keinem Konflikt. Absolut wichtig dabei: Es darf keine Felder geben, die bei jeder Änderung angefasst werden. Systemfelder ($UpdatedBy und Konsorten) sind ausgenommen.
2. Organisation. Festlegen: Wer hat wann was zu tun.
3. Workflow: Wer darf wann was ändern.

Sehr gespannt,
Bernhard

[Glombi]

Du solltest folgendes machen:

1. Wenn Ihr mehrere Server habt, auf der jeweils eine Replik liegt:
Die Replizierpriorität der Datenbank auf Hoch setzen. Für diese Datenbank extra Replikations-Verbindungsdokumente erstellen mit einem sehr kleinen Replikationsintervall.

2. Einen organisatorischen Ansatz: Bevor User lokal arbeiten, sollten Sie zunächst replizieren, um den aktuellen Stand zu haben. Nach lokalen Änderungen wieder replizieren.

Andreas

[Glombi]

Das mit dem Replizierkonflikte mischen hat aber auch Nachteile: Es können Inkonsistenzen entstehen.
Beispiel:
User A ändert in dem Dokument das Feld Ort von Frankurt in München.
User B ändert im gleichen Dokument auf einem anderen Server die PLZ von 60000 in 60100.

Was dann?

In R6 gibt es übrigens die Möglichkeit, Dokumente zu sperren, die gerade von anderen bearbeitet werden. Das solltest Du auf jeden Fall einstellen.

Andreas

[Manfred Dillmann]

Hallo dh-paule,

vielleicht ist das auch noch mal einen Blick wert:

Minimierung der Replizierkonflikte in der Praxis

Gruss
Manfred

[dh-paule]

:-(

[dh-paule]

UUPS, da war der Text weg :-(

Also hier noch ein paar Details:

Die DB beinhaltet ca. 1600 Kunden und 12000 Geräte, das sind zusammen 13600 Dokumente. Alle diese Dokumente können voan allen >100 Usern aufgerufen und bearbeitet werden. Leider replizieren nicht alle User regelmässig (täglich) sondern nur wöchentlich oder unregelmässig... So kann es immer wieder passieren das ein Dokument lokal bearbeitet wird das zwischenzeitlich schon bearbeitet wurde.

Gibt es eine Möglichkeit das Datum der letzten Replikation abzufragen ($Feld) Vielleicht liese sich daraus ein Hinweisfenster basteln:

"Achtung, Dokumente können nur geändert werden wenn die letzte Replikation nicht länger als xx h zurückliegt. Bitte replizieren Sie die Datenbank und bearbeiten das Dokument danach erneut."

Für eure Ideen danke ich schon im vorraus ;-) Spezielle Grüße übrigens nach Siegsdorf :-)

P.S: die ersten 396 Änderungen sind aktuell gelaufen, ohne das es zu Rep.Konflikten kam...

[koehlerbv]

Besondere Grüsse retour aus Siegsdorf ;-)

Gibt es eine Möglichkeit das Datum der letzten Replikation abzufragen ($Feld)  Vielleicht liese sich daraus ein Hinweisfenster basteln:

"Achtung, Dokumente können nur geändert werden wenn die letzte Replikation nicht länger als xx h zurückliegt. Bitte replizieren Sie die Datenbank und bearbeiten das Dokument danach erneut."

Jo, da habe ich was in meiner Raupensammlung. Ich schreib' mir jetzt mal 'nen groooossen Zettel und mal das mal am Wochenende auf ;-)

Herzliche Grüsse nach Jena von
Bernhard

[dh-paule]

Hallo Jungs,

vielleicht hat ja einer von euch einen Tipp...
Gibt es ein Feld an dem ich das Datum der letzten Replikation erkennen kann? Ich möchte ein Hinweisfenster anzeigen lassen das dem Anwender mitteilt da eine Änderung nur möglich ist wenn die letzte Replikation nicht länger als xxx Tage (Stunden) zurückliegt.

Hat da jemand eine Idee

[koehlerbv]

In einem Setup-Dokument belegst Du auf Deinem Hauptserver mit einem periodischen Agent ein Feld jeweils mit dem aktuellen Datum. Wenn nun ein User so vor sich hin ändern möchte, wird vorab geschaut, um wieviel in seiner Replik dieses Datum zurück in der Vergangenheit liegt. Schmeckt Dir die Differenz nicht, verhinderst Du das Ändern.

HTH,
Bernhard

[dh-paule]

uiuiui... periodische Agenten auf unseren "superschnellen" Servern :-( Von soetwas ist unsere Informatik überhaupt nicht begeistert ;-(

Ein $ Field gibt es dazu nicht

[Semeaphoros]

Nana, also das Ding, das Bernhard da vorgeschlagen hat, ist nun wirklich nicht resourcen-hungrig. Der James muss ja nur einmal am Tag rennen.

[koehlerbv]

Ein Systemfeld gibt es nicht ...

Zum anderen: Wenn Euer Server keinen Agent verträgt, der alle x Stunden ein einziges Doc anfasst und dort ein einziges Feld updated, na, dann weiss ich nicht ...

Bernhard

[dh-paule]

Ach bei unserer Informatik ist das weniger die Performance als die "Angst" vor den automatischen Agenten in DB's

[Semeaphoros]

hmm, da müsste man jetzt eigentlich eine böse Frage stellen ....

[Glombi]

Es könnte ja einer von der Informatik das Profildokument jeden Tag einmal speichern  
Das nimmt dann die Angst vor den Agenten und gibt einem ein Gefühl, eine verantwortungsvolle Aufgabe zu haben.  

Andreas

[Semeaphoros]

Genial!

Den Mitarbeiter kann man dann auch nicht nach Indien auslagern .....


 

[Glombi]

Man braucht natürlich noch einen zweiten verantwortungsvollen Mitarbeiter, der den anderen kontrolliert. Und natürlich Vertreter für Urlaub etc.
Das ganze wird in einem 10köpfigen Projektteam als Prozeß erarbeiten und ISO zertifiziert. Ein entsprechendes SLA muss natürlich auch erstellt werden.

Damit hätten wir zumindest mittelfristig so ca. 20 Arbeitsplätze gerettet.  

[dh-paule]

Hallöle,

die Idee mit den Arbeitsplätzen verlagern ist nicht schlecht. Ich werde das dann wohl zukünftig selbst machen und dazu extra nach Sydney ;-) umziehen um den Refresh mitternachts (MEZ) durchzuführen. :-)

Ich habe "meine" User jetzt angewiesen Änderungen erst nach einer aktuellen Replikation vorzunehmen und hoffe so das Maß der Konflikte niedrig zu halten... Evtl. reicht ja schon das "mischen" durch Lotus selbst.

DANKE trotzdem für eure Unterstützung !!!

[dh-paule]

Vielleicht könnt Ihr mir doch noch helfen...

Ich möchte die User nicht mit dem permanenten Hinweis nerven das Sie erst dann Dokumente ändern dürfen wenn aktuell repliziert wurde. Wenn man den Replikator aufruft dann sieht man in der ReplikatorView in der 4.ten Spalte den Zeitpunkt der letzten Replikation. Welche Variable ist das denn? Wie kann ich diese abfragen?

DANKE für eure Hinweise, mit besten Grüßen, ANDRE