Fehlermeldung: "Warnung: Ein Teil des Dokuments ..."

[koehlerbv]

Folgendes Problem:

Eine Datenbank mit fünfstelliger Anzahl von Dokumenten. Eines dieser Dokumente (erzeugt mit 6.5.1) kann plötzlich nicht mehr geöffnet werden mit folgender Fehlermeldung:
"Warnung: Ein Teil des Dokuments, das eine Funktion aus einer anderen Notes-Version verwendet, wird ignoriert." Dumme Fehlermeldung - das ganze Dokument wird ignoriert.

Die Applikation wurde ausschliesslich mit einem R5er Designer entwickelt, und die Fehlermeldung tritt unter allen mir zu Verfügung stehenden Clients auf (R5.0.8 bis R6.5.4). Die üblichen Aktionen auf die DB (Fixup etc.), das Umkopieren des Dokuments oder auch der Versuch, diesem Item via Backend noch etwas hinzuzufügen, brachten keinerlei Abhilfe.

Nach längerem Basteln fand ich die Ursache in einem RichText field. Wird dieses per Agent entfernt, lässt sich das Dokument wieder problemlos öffnen.

In dem betreffenden Dokument war das RTF gefüllt mit einem Bildchen aus dem Internet sowie frei eingegebenen Text, die Itemgrösse lieht etwas über 4 kB.

Ist jemanden sowas schon einmal untergekommen ? Macht R6 ab und an solchen Murks oder ist da nur zufällig irgendein Bit gekippt ?

Danke im Voraus,
Bernhard

[Semeaphoros]

Hatte ich auch schon, zum Glück schon länger nicht mehr. Situation sehr ähnlich, auch im Zusammenhang mit Bildern. Lösung anders als mit neu Erstellen des Dokumentes bisher nicht gefunden, allerdings ist die Häufigkeit des Problemes doch mit der Zeit zurückgegangen. Wir hatten das noch vor allem unter dem 5er Client.

[eknori]

Das Problem kenne ich. Hatte ich in unserem Organisationsverzeichnis ( ursprünglich mit R5 entwickelt ) In ein RT Feld habe ich ein Bild des Mitarbeiters importiert.
Seit R6 kommt dort auch ab und an die Fehlermeldung. Bisher hat es immer gereicht, daß Feld, welches das Bild enthält zu löschen. Danach konnte ich dann wiedr auf das Doc zugreifen.

[Semeaphoros]

Denke ich auch, dass es reicht, das Bildfeld zu entfernen, ich glaube, Ben Langhinrichs auch sowas mal gesagt hat. Bei uns waren es Internet-Seiten, die praktisch nur aus einem RT-Feld bestand, der Rest der Daten organisatorische Metadaten, daher meine Bemerkung "Neu Erstellen des Dokumentes", das ist aber tatsächlich Umständebedingt gewesen.

[koehlerbv]

Danke für Euer Feedback, Semeaphoros und Ulrich.

Unter R5 ist mir eine derartige Fehlermeldung noch miemals begegnet (allerdings muss der Client ja bereits darauf vorbereitet gewesen sein, denn die Fehlermeldungen unter R5 und R6 sind identisch und gleich idiotisch).

Interessant vielleicht noch folgendes: Das betreffende Dokument wurde nach der Ersterstellung im Rahmen eines Workflows noch mehrfach geöffnet und gespeichert. Das heisst: Der Fehler kann (auf Grund der Rechtevergaben zum Editieren und Speichern) niemals beim Einfügen des Inhalts des RTItems selbst passiert sein - zerschossen wurde das später.

Bernhard

[Semeaphoros]

So scheint es mir, ist es bei uns auch jedesmal gewesen: immer erst nachträglich zerschossen.

[DerAndre]

Hi.

Der letzte Eintrag ist zwar jetzt ein Monat her aber egal.

Ja, das ganze kann ich nun auch bestätigen. Hatte jetzt genau diese Problem.
Ein Bild eingefügt und nochmal hin und her und Ende-Gelände...
Client ist 6.51 und Datenbank bzw. Schablonski ist was älter, sollte 5er sein.

Gruss

André

[smoki]

Hallo!

Ich kenne dieses Problem auch nur zu gut und habe mich wochenlang damit herumgeschlagen. Es gibt verschiedene Gründe warum dies auftreten kann. Der Grund bei mir war, dass ich das RichText-Feld nur Anzeigen wollte (ohne das es bearbeitbar sein sollte) und habe daher ein berechnetes RT-Feld daraus gemacht. Wenn sich Screenshots und ähnliches darin befinden, kommt es nach mehrmaligen Speichern zu den genannten Fehler.

Mein Workaround ist folgender:

Das Rich-Text-Feld wird als "bearbeitbar" definiert.
Und drum/herum wird ein Berechtiungs-Abschnitt gelegt und dieser verhindert, dass der Inhalt dieses Abschnitts von irgendwem editiert werden kann. Der Abschnitt selbst wird mit der hintergundfarbe unsichtbar gemacht. Seitdem (ca. 1 Woche) habe ich nun keine Problem mehr, vielleicht hilft das bei dir auch? 

Gruß
Smoki

[DerAndre]

Uiuiui, schon über ein Jahr her, aber ich grab das Teil trotzdem nochmal aus.

Wir haben jetzt wieder dieses Problem. Auf Notes.Net habe ich dann mal nach

"Warning: Ignoring portion of document that uses a feature from another version of notes."


gesucht und auch was gefunden.

Positiv ist schonmal, man sich das Dokument über das Web aufrufen, dann sollte es ohne die Korrupten Bilder angezeigt werden.
Ich werde mal weitersuchen, ob es da eine Möglichkeit der Rettung gibt ohne die Felder zu löschen, Beispiele sind im Notes.net vorhanden.  Mal schauen, ob es klappt.

[Hive]

Ich habe das mal auf ein bild-ressource zurückführen können diein ein RT-Field ein gebunden wurde.

KAI

[smoki]

Es sind auf jeden Fall immer Bilder...

Nach meiner Beobachtung war das folgendermaßen:

Das Bodyfeld wird ja mehrfach im Dokument gespeichert, wenn es über 64KB hat.

Beim Speichern wird allerdings dann nur das erste Element des Feldes gespeichert und nicht mehr alle Elemente, dadurch ist das Bodyfeld unvollständig.

Kann das Feld in irgendeiner Maske/Teilmaske/Status mit "Berechnet" definiert sein? Das sollte immer vermieden werden. Da ich nur in solchen Fällen bisher Fehler feststellen konnte.

Sollte dein Sachverhalt so sein, kann man den Inhalt auch ohne Bild nicht wiederherstellen, da auch der Rest >64KB fehlt...(Vielleicht irgendwie die ersten 64KB!)

Allerdings glaube ich nicht, habe es damals aber nie getestet, dass man in meinen Fall das Bild über den Browser sehen konnte, wenn es bei dir geht, ist es vielleicht eine andere Merkwürdigkeit mit dem gleichen Fehler.

Gruss
Chris

[DerAndre]

Hallo Chris.

Stimmt, hab ich vergessen dazuzuschreiben, der Text ist sichtbar, die Bilder allerdings nicht.

Deiner Theorie stimme ich zu, es liegt an Richtextfeldern die Berechnet sind. Ist hier auch der Fall.
Allerdings zeigen die Eigenschaften des Feldes nur eine Größe von 254 Byte an. Es scheint also unabhängig von der Größe zu sein.

[Bastel123]

Hallo,

das ganze gibt es auch noch unter R7.

In den KB gibt es ein Dokument dazu.

http://www-1.ibm.com/support/docview.wss?uid=swg21097112

Gruß Bastel123

[DerAndre]

Danke für die Info.

Ich würde mal sagen die haben ihre Rich Text Felder immer noch nicht wirklich im Griff... 

[immanuel]

Hallo Zusammen

Wir bekommen seit kurzem auch die Fehlermeldung. Situation: Notes 6.5.2 - 6.5.5 DE/ENG, wir fügen neu jedem Mail per Template ein kleines Bild hinzu. Es ist eine Kommunikations-Aktion. Bei einem Reply  auf ein Mail mit Bildern kommt es vor, dass wir die Fehelrmeldung erhalten. Bei einem Forward tritt das Problem jedoch nicht auf. Bei 40 Kb Mailgrösse ist das Problem auch aufgetreten. Die Fehlermeldung kommt aber nur, wenn man einen Reply machen möchte, nicht wenn ein grosses Mail nur geöffnet wird.

Unser Bild, das wir einfügen ist ca. 6KB gross. Wir fügen ein ganzes Richtextfeld per DBLookup als Defaultwert ins Body Feld ein. Dadurch wird immer zuunterst bei einem Mail unseren gewünschten Contet hinzugefügt.

Habt ihr einen Lösungsvorschlag?

Grüsse
Manuel

[pete_bla]

Ok das Thema wurde laaaaange nicht mehr bearbeitet, ist aber genau das!

Zu meiner Baustelle:
Ich hab eine Datenbank geerbt in der es etliche RichText-Felder die zuerst bearbeitbar, später im Workflow berechnet aus sich selbst sind.

Nun teste ich auch in Hinblick auf eben diesen Fehler und habe für bestimmte "beschädigte Dokumente" mit importierten Bildern drin folgendes festgestellt:

- R6.55en bringt diesen genannten Fehler (wie schon erwartet)
- R7.02en bringt den Fehler nicht mehr...

zuerst dachte ich: "endlich gefixt"

... aber zu früh gefreut:
die Felder sind genauso "leer",
es wurde wohl nur die Fehlermeldung "gefixt",
nicht jedoch das eigentliche Problem mit den berechneten RichText-Feldern und den Images!

Jetzt mach ich mich noch dran das mit R8 zu testen, aber eigentlich ist es nicht notwendig,
da ich den Teil sowieso überarbeiten muss. (-> kontrollierter Abschnitt.)

Gruss, Pete(r)

[koehlerbv]

Es ist genau dieses Zusammenspiel RTItem mit wechselnder Einbindung (bearbeitbar / berechnet) im Frontend.

Ich habe gerade letztens wieder so einen "Fall" auf den Tisch bekommen. Interessanterweise konnte ich die betroffenen Dokumente mit einem 6.5.6er Client öffnen (7.0.2 habe ich m.E. nicht hergenommen), alle älteren Versionen meckerten mit der bekannten Meldung.

Was spricht eigentlich gegen zugriffskontrollierte Abschnitte, um ggf. die Bearbeitung zu verhindern?

Bernhard

[pete_bla]

zu Richtext-Feldern gehört das zu den "Best Practices"
- sie nicht: zum einen "bearbeitbar" und zum anderen "berechent" zu verwenden
- sie nicht: in Tabellen zu packen
- sie nicht: mit Verbergeformeln zu versehen
[...]
sonst wundert man sich eines Tages!

Und dass diese Fehlermeldung nicht mehr kommt ist nicht schön!!

-> Es ist ein Problem, das im Verborgenen liegen wird, da es nur noch heisst:
"Meine Bilder sind weg" "natürlich habe ich was reingeschrieben"
wenn es überhaupt mal auffällt!

Gruss, Pete(r)

[koehlerbv]

Und dass diese Fehlermeldung nicht mehr kommt ist nicht schön!!

Nicht, dass ich missverstanden werde, Pete: Der 6.5.6er Client zeigte bei mir nicht nur nicht mehr die Fehlermeldung, sondern statt dessen das RTI korrekt an, während 6.5.3, 6.5.4 und 6.5.5 meckerten (und gar nichts mehr anzeigten, wie wir es ja kennen).

Ob das für jedes "zerlegte" Dokument gilt, vermag ich nicht zu sagen.

Bernhard

[pete_bla]

Hi,

und nochmals wärme ich den Thread auf - ich finde er bleibt aktuell, auch wenn er ins Mystische verschwinden könnte....

In meinem speziellen Fall habe ich es nun auch mit dem 6.56er (en) getestet und es hatte den selben Effekt wie mit dem 7.02:
keine Fehlermeldung und keine Daten mehr!

Also Merke an alle:
RT-Felder immer hübsch bearbeitbar lassen, wenn sie das mal waren!

Gruss, Pete(r)

zu meiner Baustelle:
hier bin ich noch am überlegen, wie ich dem Kunden das erkläre, dass ich den Teil auch überarbeiten muss, und er dafür etwas Budget haben sollte....
Wenn es nur ein RT-Feld wäre hät ichs ja mal "gschwind gmacht"...