Änderungen in Dokumenten werden beim Speichern nicht geschrieben

[w3dev]

Hallo liebe Gemeinde,

ich hab hier gerade ein Phänomen, welches ich so zum ersten mal sehe.

Beim Speichern von bearbeiteten Dokumenten werden bei einem Kunden die Änderungen nicht übernommen. Das Dokument hat beim erneuten Öffnen, auch beim Blick in die Dokumenteigenschaften, die alten Feldinhalte.

Wenn ich von meinem Client auf dem selben Server zugreife geht's wie immer ohne Probleme.

Das ganze trat auf, ohne Änderung/Update des Designs bzw der DB-Eigenschaften oder ACL.

Hat die (Notes-) Welt sowas schon gesehen?

Gruß Ronny.

[m3]

Das ganze trat auf, ohne Änderung/Update des Designs bzw der DB-Eigenschaften oder ACL.

Sagt wer? Ist sicher gelogen.

[w3dev]

Die Designs ändern nur wir und Edit-Zugriff auf die Dokumetne besteht.

Update-Info:
Nachdem ich von meinem Client ein Dokument auf dem Server geändert habe, kann der Kunde das Dokument auch einmal speichern. Danach werden die Änderungen wieder nicht mehr übernommen.

[koehlerbv]

An "Auf einmal ..." und so glaube ich auch nicht - hierfür muss am Code geschraubt worden sein. Ich würde erstmal das Design nach "SaveOptions" durchsuchen, das / die QuerySave-Events checken etc.
"Von alleine " oder weil "Notes schlechte Laune hat" kommt sowas nicht.

Bernhard

[w3dev]

Save Options hat damit nichts tun, das ganze geht auch nicht beim Speichrn mit strg-s. Ich glaub ja auch nicht an "Auf einmal...". Ich finde nur keine Begründung und auch keine Möglichkeit mehr, was ich noch prüfen kann.

Wie gesagt von meinem Client aus gehts ja (selbe DB auf selbem Server). Am Design schrauben nur wir. Und Maskenaktionen wie "querySave" sind auch keine angegeben.


Gruß Ronny

[m3]

Nachdem ich von meinem Client ein Dokument auf dem Server geändert habe, kann der Kunde das Dokument auch einmal speichern. Danach werden die Änderungen wieder nicht mehr übernommen.

Das klingt für mich nach einem Reader/Author Feld Problem. Habt ihr solche in der App? Ev. mit Gruppen eingetragen und diese Gruppen wurden im Domino Directory verändert?

[w3dev]

Gruppen sind keine in Schreib-/Lesefeldern eingetragen. Wie gesagt, in den bearbeitungmodus gehts ja. Beim Speichern kommt auch keine Fehlermeldung. Die Daten werden halt nicht ins Backend geschrieben. Nach Schließen und erneurtem Öffnen ist die Änderung nicht im Dokument.

Das ganze betrifft verschiedene Dokumente mit vverschiedenen Masken. In den geänderten Feldern findet auch keine Feldberechnung statt.


Gruß Ronny

[koehlerbv]

Save Options hat damit nichts tun, das ganze geht auch nicht beim Speichrn mit strg-s.

Äh ... Warum sollte Strg-s das Item SaveOptions aushebeln? SaveOptions = "1" betrifft alle Frontend-Speicherbemühungen.

@Martin: Effekte durch Autorenfelder (Leserfelder können hier gar nicht in Frage kommen) würden aber  zu einer Fehlermeldung führen.

Bernhard

[w3dev]

Das Feld "SaveOptions" ist weder im Dokument vorhanden noch wird es in der Maske als "Berechnet zur Ansicht" verwendet.

Kann die DB vielleicht defekt sein? Wobei, von meinem Client aus geht's ja.


Ronny

[koehlerbv]

Ich will auf SaveOptions nicht herumreiten (auch ein Continue = False an unpassender Stelle und in Abhängigkeit von den Userrechten ist denkbar und ...), aber:
Wieso sollte man in einer Maske ein Feld "SaveOptions" haben müssen, um das Item zu verwenden? Ich arbeite (oft) mit SaveOptions, man wird das aber in keiner Maske finden. Und abgespeichert wird das Item dann sowieso nicht - genau das verhindert ja SaveOptions = "1"!

Wenn Du jetzt sagst: Ich habe das Design mittels Teamstudio Analyzer oder (aufwändig) via Gestaltungsübersicht durchforstet, und "SaveOptions" kommt da nicht vor: Dann können wir andere Ansätze verfolgen. Wenn Du aber nicht weisst, wie man SaveOptions überhaupt einsetzt / einsetzen kann, dann wird es mit weiteren Tipps schwierig.

Bernhard

[w3dev]

"SaveOptions" kommt ausser in einem Abbrechen Button nirgends in der DB vor. Analysiert mit TeamStudio Configurator, wie gewünscht. 

[datenbanken24]

Prüfe doch mal über die Property-Box, ob es Felder in Deinen betreffenden Dokumenten gibt,
die die FELD-Eigenschaft / Feld-Flag: "PROTECTED" haben.
Das ist was anderes als Authorenzugriff oder Lesezugriff auf ein ganzes Dokument.

Mit einem ähnlichen Problem schlagen wir uns bei einem Kunden seit Monaten herum - wie diese verflixte Feld-Eigenschaft "PROTECTED" da "benutzerabhängig" rein kommt...

Mehr dazu nur, wenn das wirklich auch bei Dir drin stehen sollte...

Gruß,
Uwe

[m3]

Hmmm. Bernhard hat natürlich recht (wie meistens).

Andere Frage: Nachdem das Problem auf einem Client auftritt, auf dem anderen aber nicht - wie seiht das aus, wenn Du mit der ID des Kunde auf Deiner Maschine arbeitest? gehts dann?
Wenn ja, schon mal chache, etc. gelöscht? Ev. hat sich ja was lokal bei dem User verrannt.

[w3dev]

@Datenbanken24: Ich hab tatsächlich in den von den betroffenen Usern bearbeiteten Feldern das Flag "PROTECTET" drin.

Das is ja mal 'n klasse Tipp gewesen, herzlichen Dank. Jetzt interessiert mich natürlich auch was bei euch das Problem ist.

Merci, Ronny

[datenbanken24]

Oh - dann wird's böse.
Wir haben das Problem bisher nicht gelöst - nur umgangen, indem wir dem betreffenden Benutzer erst mal  "Editor"-Rechte geben mußten, anstelle von Author-Rechten.

So stellt sich das bei uns dar,
eine Sache eben, die eigentlich gar nicht sein KANN,
wo wir alles schon durchsucht haben - und einfach nix finden:

Ein ganz bestimmter Benutzer (Author) speichert Dokumente und haut dabei in vier immer gleiche Felder,
einen PROTECTED Feldschutz rein. Diese vier Felder haben dann die Feldeigenschaft "PROTECTED",
(siehe Screenshot). Nur bei diesem Benutzer - bei anderen passiert das nie.

Der User kann nach dem Speichern das Dokument nicht mehr bearbeiten -
bzw. Speicherungen werden nicht mehr wirksam
und kann es nur noch einmal zum Server replizieren.

Wenn der PROTECTED Schutz bei diesem Dokument repliziert ist, können die anderen User (auch Authoren, aber alle im Authoren-Feld) dieses Dokument nicht mehr bearbeiten oder schreibend replizieren. Das ist auch logisch, weil ein Author ein Dokument nicht mehr bearbeiten kann, wenn ein Feld darin die Feld-Eigenschaft "PROTECTED" hat und er nur Author ist - AUCH wenn er in einem Authorenfeld steht.

Es gibt (in unserem Fall) KEINE einzige Zeile Code in der Anwendung, die ein Feld programmtechnisch protected, das ganze Wort "PROTECTED" oder "IsProtected=" kommt nicht ein einziges mal im gesamten Sourcecode der Datenbank vor - das ist sicher, dafür gibt es Tools. Außerdem ist die Anwendung selbst geschrieben und wir nutzen keine PROTECTED Feldeigenschaft. Und natürlich haben die Felder in der Maske auch nicht die Eigenschaft "Must have at least Editor access to use".
Der Anwender hat auch keinen PDA-Abgleich oder kein Dritt-Tool, was er über die Anwendung jagt.

Das ist der aktuelle Stand, leider ohne Lösung.
Kein Mensch weiß, warum immer bei einem bestimmten Benutzer diese Feldeigenschaft gesetzt wird.

Gruß,
Uwe

[w3dev]

@Uwe: Danke für deine Antwort. Ich hab gerade deinen Beitrag hierzu in einem anderen Thread gefunden. Bei uns scheint das Problem das gleiche zu sein. Ich hab die Anwednung selbst entwicklet und kann auch mit Sicherheit sagen, dass ich ebenfalls programatisch nicht mit dieser Funktion ("PROTECTED") arbeite.

Ich werd mich jetzt auch mal schlau machen. Vielleicht find ich ja was. 4 Augen sehen mehr als 2 und 2 Hirne denken mehr als eins. 

Wenn ich was hab sag ich in diesen Thread auf jeden Fall bescheid.

Gruß und Dank


Ronny

[datenbanken24]

Nicht zu vergessen zu erwähnen,
dass wir neben den üblichen "Notes-Reinigungsmethoden"
bei diesem User sogar das Notes vollständig platt gemacht und neu installiert haben
und auch die Anwendung komplett neu auf den Laptop repliziert haben.

Und dann noch (extra, bei einem zweiten Lauf) von R5 auf ND 6.55 umgestiegen sind.

Und nach einer Woche ging das gleiche Spiel wieder los....

[w3dev]

Danke für die Infos zu euren Aktivitäten. Dann muss ich dass nicht auch nochmal probieren. Ich werd da jetzt vielleicht mal von der Server-Seite her rangehen. Mal schaun was der Admin sagt.

Ich meld mich. Gruß

Ronny

[w3dev]

Also,

ich hab da einen Thread und einen Workaround bei IBM gefunden zu diesem Problem:

Thread: http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/674b6e8a3e1967e585257130004b7e95?OpenDocument

Workaround: http://www-1.ibm.com/support/docview.wss?rs=899&uid=swg21237167

Hab das ganze allerdings nocht nicht Ausprobiert.


Gruß Ronny

[datenbanken24]

Danke Ronny,

das tut erst mal gut zu wissen, dass man nicht an Wahnvorstellungen leidet
und dass man nicht der einzige ist, bei dem diese verrückte Geschichte vorkommt.
Scheinen ja nun doch ne ganze Menge Leute mehr zu sein, bei denen das auftritt. Wir hatten damals keinen einzigen gefunden.

Naja und ob Du bei IBM für sowas einen ServiceRequest aufmachst
oder lieber gleich eine Woche in Urlaub fährst,
kommt ja meist auf's gleiche raus.

Im Real Business kann man für sowas leider nicht unendliche Manntage "verforschen", sondern muss schnell eine Lösung finden - und das war eben der "Editor" - wie sie im IBM Forum nun auch schreiben.

Im Gegensatz zum IBM Forum haben wir das, wie beschrieben, auch schon mit R5 und Notes 6.

Mal sehen, wie's weiter geht.

Gruß
Uwe