Das Notes Forum
Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: Christian Kröll am 12.05.11 - 16:19:50
-
Hallo atnotes-Gemeinde,
seit Tagen lässt mir folgendes Problem keine Ruhe, dass ich wegen der vielen vergeblichen Lösungsversuche ausführlicher beschreiben muß:
In einem Stammblatt liegen zentral Informationen zu einem Auftragsvorgang von der ersten 1. Anfrage bis zur Schlußrechnung.
Die Mitarbeiter können über Schalter gut 40 verschiedene Aktionen ausführen (Freigaben, Bestellungen auslösen, Proforma-Rechnungen erstellen usw.)
Seitdem wir diese Maske eingeführt haben, sorgt sie permanent für Replikations- und Speicherkonflikte:
- Eine gleichzeitige Bearbeitung von mehreren Mitarbeitern gibt es nicht und
- es greifen keine Agenten auf diese Dokumente zu oder werden von Benutzern ausgelöst.
- Die Maske enthält keine berechneten Felder, kein DBPath-Feld o.ä.
- kein "Felder aktualisieren" (Maskeneigenschaften)
- Im QuerySave wird nur für den Fall, dass im Projektverlauf aus einem Interessenten eine Kunde mit entspr. Kundennummer wurde, die neue Kundennummer gezogen und gespeichert. Bei 95% der Speicherkonflikte war die Kundennummer bereits bei der Anlage vorhanden und daher die QuerySave ohne weitere Aktion beendet.
- Es gibt nur drei Eingabefelder und der Konflikt entsteht unabhängig, ob hier etwas geändert wurde oder nicht.
Die Datenbank ist mit einem zweiten Server in einem Cluster und die Maskeneinstellung für Replikationskonflikte steht auf "Mischen/Keine Konflikte". Allerdings arbeitete niemand auf dem zweiten Cluster-Server. Natürlich dort auch keine Agenten etc. Lokale Repliken gibt es nicht.
Die Speicherkonflikte kann ich beliebig auslösen, wenn man zB. nur den Status des Projektes verändert oder sich als Bearbeiter einträgt.
Konkretes Beispiel: die Mitarbeiter können sich als Bearbeiter eintragen (Aktion)
1. Versuch (Formel)
@Command([EditDocument];"1");
FIELD Bearbeiter := @Name([CN];@UserName);
@PostedCommand([FileSave]);
@PostedCommand([EditDocument];@False);
2. Versuch Script: (egal, ob mit oder ohne speichern)
Dim ws As NotesUIWorkspace
Dim s As New NotesSession
Dim uidoc As NotesUIDocument
Set ws = New NotesUIWorkspace
Set uidoc = ws.CurrentDocument
If uidoc.EditMode=False Then uidoc.EditMode=True
Call uidoc.FieldSetText("Bearbeiter",s.CommonUserName)
3. Versuch mit Script:
ID des Backenddokuments holen, im Frontend ändern, speichern, schließen, Frontend Objekt löschen (mit Delete uidoc bzw. Delete doc) und als neues NotesDocument zum bearbeiten öffnen (hier im Forumzweimal erwähnt, den Code muß ich hier nicht wiederholen)
4. Versuch mit Script (mit uidoc.Reload)
Dim ws As New NotesUIWorkspace
Dim s As New NotesSession
Dim doc As NotesDocument
Dim uidoc As NotesUIDocument
Set uidoc = ws.CurrentDocument
Set doc = uidoc.document
uidoc.EditMode = True
Call doc.ReplaceItemValue("Bearbeiter",s.CommonUserName)
call uidoc.reload
Call uidoc.save
uidoc.EditMode = False
Also ich bin jetzt wirklich ratlos. Es ist gleich, ob der Code in einer Aktion oder einer Schaltfläche steckt. Selbst der Gedanke, die Maske hat einen Schuß weg brachte nichts. Auch in der neuen Maske gleiches Ergebnis...
-
Kannst Du die Maske mal soweit verkleinern, dass das Problem noch auftritt, aber keine Betriebsgeheimnisse verraten werden, und dann hier posten? Das würde ich gerne mal nachstellen
-
Warum machst Du diese Änderungen immer im Frontend?
Wenn es dann kracht, liegt nahe, dass beim Frontend-Speichern (oder gar schon beim Öffnen?) ein weiterer Prozess (Event?) läuft.
Bernhard
-
aber klar - ich hoffe die rausgelöste Datenbank hilft.
Das Dokument 1 ist so ein Stammblatt
-
Hallo Bernhard,
gerade um zu vermeiden, dass die Mitarbeiter die wenigen Felder im Frontend ändern und dann im Backend vielleicht den Status des Projekts verändern. Das rumpelt doch unter Garantie ?!
-
Die Datenbank hat lokalen Zugriffsschutz
-
sorry - ich lerne ;-)
-
Offensichtlich nicht ;D
Das Teil ist immer noch verschlüsselt!
Bernhard
-
Verschlüsselung vs. Zugriffskontrolle.... ja!
-
Hm, also ich kann da Knöpfe drücken, wie ich will. Einen Replizierkonflikt bekomme ich nicht.
-
Wie erwartet: Es ist das QuerySave. Überlege Dir da einfach Zeile für Zeile (und im Gesamtkontext), was für einen extremen Murks Du da programmiert hast.
Schmeiss das wertlose Zeug einfach weg. Mach es neu. Und dabei sind wir sehr gerne behilflich!
Bernhard
-
Hm, also ich kann da Knöpfe drücken, wie ich will. Einen Replizierkonflikt bekomme ich nicht.
Klar - die Bedingungen im QuerySave schlagen ja in dem Textkontext nicht zu, Peter.
Bernhard
-
@Bernhard: nun, ich dachte, ich erlebe erst einmal das Problem, und dann schaue ich tiefer.
@Christian:
1. Du speicherst im Querysave das Dokument separat im Backend, das muss krachen. Wozu machst Du das, das Dokument wird doch sowieso gerade gespeichert?
2. Im Querysave musst Du nicht prüfen, ob das Dokument im Edit-Modus ist. Im Lese-Modus wird das Querysave nicht ausgeführt (das führt allerdings nicht zu Deinem Fehler, macht das ganze nur nicht gerade leserlicher)
-
Christian, wenn eine Diskussion in einem AtNotes-Board am Laufen ist, führe ich keine zweite per PM.
Ich kann Dir nur empfehlen: Wird den Murks aus QuerySave 'raus. Beschreibe (Dir oder uns) genaz genau, was Du erreichen willst. Vergiss dabei QuerySave - es gibt ja noch andere Wege, sein Ziel zu erreichen. Dewnke immer an den Konflikt zwischen Frontend und Backend.
Bei genauer Überlegung wird Dir sicherlich selber ein Licht aufgehen. Und bei Fragen stehen wir wirklich gerne mit Rat zur Seite!
Bernhard
-
Ihr habt Recht - vielleicht aber auch etwas übersehen:
Das QuerySave kommt nicht bis zur Zeile
flag = doc.Save(False, False)
Selbst wenn, vorher wurde doch mit
Set doc = view.GetDocumentByKey("System")
ein völlig neues Dokument gerufen und auch gespeichert, falls nötig.
Mitarbeiter im Vertrieb erstellen eine Anfrage mit einem eigenen Notes-Dokument. Wenn die gespeichert wird, erzeuge ich im Hintergrund das fragliche Stammblatt und vergebe die Nummer ("FDJobNr"). Daher läuft der Code auch immer in das Exit Sub.
Es gab die Situation, dass Mitarbeiter mal ein Stammblatt gelöscht haben. Um es schnell neu anlegen zu können, habe ich die Nummernvergabe hier überhaupt aufgenommen.
Zur Klarheit wäre ein neuer Bezeichner leichter zu lesen.
Habe nun das QuerySave trotzdem mal komplett geändert auf vier Zeilen:
If Source.FieldGetText("CustomerNr") = "" Then
Msgbox "Bitte Kundennummer eintragen"
continue = False
End If
Damit mache ich wohl nichts falsch?
Effekt: Weiterhin Speicherkonflikt...
Ich bin weiterhin wirklich sehr dankbar für Eure Hilfe und jede Anregung.
-
Schreib doch mal, wie ich den Konflikt reproduzieren kann, dann setze ich mich morgen da mal ran
-
Diese vier Zeilen erzeugen nie und nimmer einen Speicherkonflikt. Da muss noch ein weiterer Prozess laufen.
Wenn Du - wie Peter schon schrieb - eine Version hinbekommst, mit dem wir das nachvollziehen können, dann ist auch der Fehler schnell gefunden. Aber eigentlich müsstest Du das auch selbst mit dem Debugger hinbekommen.
Bernhard
-
Ich versuche Euch morgen eine DB zu posten, mit der Ihr den Effekt nachvollziehen könnt - sitze gerade dran.
Falls nicht: Das Oktoberfest kommt ja irgendwann ;)
-
wie eigentlich schon vor dem Post meines Problems geprüft, am Code liegt es nicht:
Das Setzen der Werte ist richtig und das QuerySave Event war keine Beauty (Danke für das deutliche Draufstossen, Bernhard), läuft aber auch wie gewünscht. Im Debugger waren nie weitere Prozesse zu sehen.
Beim vergeblichen Versuch, Euch lokal eine Db zu erstellen, die auch den Konflikt bringt, kam mir der Gedanke, dass doch vielleicht im Cluster ein Bug sein könnte. Wie Bernhard sagte, alles Stop und auf Anfang (allerdings im QuerySave...)
Agenten und Programme laufen dort keine, also nochmals zum IBM-Support. Dortbin ich bei auf APAR LO52374 gestossen (https://www-304.ibm.com/support/docview.wss?uid=swg1LO52374 bzw. https://www-304.ibm.com/support/docview.wss?uid=swg21444933).
Zusammenfassung:
Mehrfach gespeicherte Dokumente in einer geclusterten Anwendung sind mit der Maskeneigenschaft "Konflikte erstellen" erstellt worden, also kein $ConflictActions-Feld. Später wurde die Eigenschaft auf "Mischen/Keine Konflikte" geändert. Wenn nun das Dokument erneut gespeichert wird, dann wird das Feld $ConflictAction="3" erstellt. Das führt dann aber zu einem Replikationskonflikt im Cluster.
Lösung ist simpel: Replikation stoppen, Design auf beiden Repliken ändern und das Feld $ConflictActions ersetllen/auf "3" ändern, Replikation starten.
Hier in meinem Fall: Das Stammblatt, dass hier zum Konflikt führt, wird beim Speichern eines anderen Dokuments im Hintergrund erstellt und mit Daten gefüllt. Auch spätere Änderungen laufen im Hintergrund in das Stammblatt. Erst wenn die Mitarbeiter direkt mit dem Stammblatt arbeiten und speichern, wird das $ConflictAction erstellt. Dann macht's natürlich "Puff".
Das sieht dann leider so aus, als hätte man einen Speicher- und keinen Replikationskonflikt.
Diesen Thread können wir bitte schließen. Bernhard und Peter - Euch vielen Dank!
-
Faszinierend - da muss man erstmal drauf kommen! Respekt!
Bernhard
-
Danke für die Rückmeldung, das Thema wurde hier schon einmal diskutiert, vielleicht vor einem halben Jahr (?).
Hatte mir Dein QuerySave auch nochmal angeschaut, Du hattest natürlich Recht, es wurde nicht das aktuelle Dokument im Backend gespeichert. Daran sieht man, dass es nicht günstig ist, eine Variable mehrfach zu verwenden (erst das doc auf das aktuelle Dokument setzen, dann auf ein anderes umbiegen und speichern, da muss man schon sehr genau hinschauen). Aber gemeckert ist schnell, ich bin sicher, dass sich Ähnliches bestimmt auch in meinen Codes finden wird, was ich aber niemals zugeben würde ;) ...
-
Zur Ergänzung hier der Thread, den Peter meint:
http://atnotes.de/index.php/topic,49091.0.html