Domino 9 und frühere Versionen > ND8: Entwicklung

Speicherkonflikt tritt immer wieder auf

(1/5) > >>

Christian Kröll:
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...

Peter Klett:
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

koehlerbv:
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

Christian Kröll:
aber klar - ich hoffe die rausgelöste Datenbank hilft.
Das Dokument 1 ist so ein Stammblatt

Christian Kröll:
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 ?!

Navigation

[0] Themen-Index

[#] Nächste Seite