"Gemeinen" 32K/64K Fehler entdeckt

[pram]

Hallo, Ich verwende zum Zwischenspeichern von Informationen Temp-Dokumente (im Backend, werden nicht gespeichert) um darauf dann mit LS-Evaluate eine Formel anzuwenden:

Dabei ist mir folgendes Verhalten aufgefallen, welches ich euch gerne mitteilen möchte:
Existiert in einem Dokument ein Feld NICHT, so kann ich bis zu 64000 Zeichen (=normale Zeichen, keine Sonderzeichen) in das Feld schreiben.
(€-Zeichen geht nicht, da dies intern wohl 2 Bytes benötigt)

Existiert das Feld, so kann ich nur noch 32000 Zeichen in ein Feld schreiben. Versuche ich mehr zu schreiben, bleibt der alte Wert und es kommt auch kein Fehler
=> Dass mit den Daten was nicht stimmt, fällt nun nicht auf
Beispiel:

Code

doc.s=string(66000,"a") => ergibt einen Fehler (und das ist auch i.O.)
doc.s=string(64000,"a") => Feld s enthält 64000 a's
doc.s="Hallo"           => Feld enthält den Wert "Hallo"
doc.s=string(66000,"a") => Es kommt KEIN FEHLER (müsste aber). Der Wert des Feldes bleibt auf "Hallo"
doc.s=string(64000,"a") => Feld enthält IMMER NOCH den Wert "Hallo". (2 Zeilen darüber konnte der String aber geschrieben werden!)
doc.s=string(32000,"a") => Feld enthält 32000 a's. Erst wenn der String < 32k ist, kann er wieder ins Feld geschrieben werden

ich hab auch schon anstatt "doc.s=..." ein "doc.replaceitemvalue("s"...)" probiert.

Hier ist mir aufgefallen, dass doc.s=string(66000,"a") einen "Could not create field %1" erzeugt.
Replaceitemvalue hingegen einen "Memory Allocation request exceeded 65000 bytes" Fehler.
Das Verhalten, dass beide Methoden das Feld nicht mehr verändern, wenn es existiert, ist (leider) gleich.

Notes-Version ist 8.5.3

(Mir ist klar, das alles über 32K ein Problem für Notes ist. Das oben beschriebene Verhalten ist aber meiner Meinung nach alles andere als "normal", es hat auch eine Zeitlang gedauert, bis ich rausgefunden habe, warum Evaluate immer noch Werte aus dem vorherigen Durchgang verwendet hat...
Als Workaround werde ich wohl davor ein removeItem absetzen müssen)

Gruß
Roland

[marschul]

Danke für die Info!

Ein Feld-Speicherproblem hatte ich auch mal im Rahmen eines WebServices (LN = Provider), bei dem ein anders System über den WS einen recht langen String übergeben hatte, welchen wir zu Protokollzwecken in Dokumenten gespeichert hatten. Damit sollte erkennbar sein, was uns angeliefert wurde. Lief gut, bis das erste Dokument nicht mehr geöffnet werden konnte aufgrund Feldgröße überschritten. Würgaround war, mit einem RichTextItem zu arbeiten - funzte aber anstandslos

[Glombi]

Das hängt mit dem isSummary Flag für Felder zusammen.

[marschul]

Das hängt mit dem isSummary Flag für Felder zusammen.

Bedeutet das, wenn ich das Flag auf False setze, kann ich mehr im Feld speichern, ohne dass Notes beim Zugriff auf das Doc rumzickt?

[pram]

Richtig, wenn isSummary = FALSE ist, dann kann man mehr als 64K im Dokument speichern (und mein obiger Code läuft dann auch wie erwartet durch)

hab übrigens gerade rausgefunden, dass bei "new notesItem" schon bei 32K schluss ist, mit "doc.replaceItemValue" aber Items mit 64K angelegt werden können.  Weiterhin ist das Verhalten unterschiedlich ob ein String oder ein Array mit einem String geschrieben wird (letzteres bringt einen Fehler)

... alles sehr verwirrend (deshalb am Besten keine so langen Feldinhalte verwenden )

Gruß
Roland