Das Notes Forum
Domino 9 und frühere Versionen => ND9: Entwicklung => Thema gestartet von: Lancelot am 10.10.16 - 15:09:41
-
Hi Leute,
wir habe eine selbst entwickelte Projekt-Anwendung.
Die ist nichts besonderes, aber es gibt ein RichText-Feld indem alles was zu dem Projekt getan wird von MA zu dokumentieren ist.
Jetzt aber haben MA dies als Protokollmöglichkeit für Termine entdeckt und kopieren dazu immer den letzten Abschnitt (33 DIN A 4 Seiten, 9689 Wörter, 64800 Zeichen und 292 Absätze)
mit allen besprochenen Themen als neue Besprechungsgrundlage aus einem RichText-Feld und fügen es in das gleiche RichText-Feld nur eine Zeile drüber wieder ein.
Nach 12 Kopiervorgängen des Abschnitts war Schluss und es kam folgende Meldung "Feld ist zu groß (32K), oder die Spalten- oder Auswahlformel der Ansicht sind zu groß"
Ich soll jetzt die Meldung so abfangen, dass wenn ein User diese Meldung mit "OK" bestätigt, soll das Projekt nicht geschlossen werden, damit nicht alles andere was eingetragen wurde verloren geht.
Ich habe rausgefunden, dass die Fehlermeldung zwischen dem Ereignis "QuerySave" und "PostSave" angezeigt wird, habe aber keine Ahnung wie oder besser gesagt wo ich die Meldung abfragen muss, um das Dokument nach schließen der Fehlermeldung offen zu lassen?
Hoffe ihr könnt mir folgen und mir etwas Starthilfe geben.
Vorne weg schon mal ein herzliches Dankeschön.
-
Hallo,
Das hier ein "Richt Text" Feld zuschlägt, kann ich mir nicht so ganz vorstellen.
siehe hier (https://www.ibm.com/support/knowledgecenter/SSVRGU_8.5.3/com.ibm.designer.domino.main.doc/H_NOTES_AND_DOMINO_KNOWN_LIMITS.html).
Und das hier bereits 1 GB erreicht werden, ist eher unwahrscheinlich.
Also muss hier noch etwas anders zuschlagen.
Andreas
-
Hallo Andreas,
es wird aber nichts anderes im Dokument gemacht.
Die kopieren nur den Abschnitt rein und wollten das Dokument speichern.
Alle anderen Textfelder kommen laut Eigenschaften-Box nicht an die 32 K -Grenze hin.
Ich habe aber gerade in den Eigenschaften gesehen, dass dieses RichText-Feld mit samt Inhalt 72x kopiert wurden.
Kann das der Grund sein.
Bleibt aber noch die Frage wo ich die Meldung abfragen kann, damit ich das schließen des Fensters verhindern kann.
-
Das ist eindeutig ein Überlauf des Summary Buffers. hast du mal geguckt, ob die SUMME der Feldgrößen die 32k Grenze erreicht?
Speziell die Felder $ModifiedBy, $UpdatedBy gehen gerne schon mal gegen Unendlich, wenn man das in den Datenbankeigenschaften nicht abfängt.
Den Fehler selber kannst du an der Stelle nicht mehr behandeln; die Grenze ist erreicht und Ende Gelände.
-
Du kannstes ja mal mit einem
On error 4000 continue = false
Im QueryClose event das doc probieren.
-
Weitere Fehler in diesem Zusammenhang, die das Dokument unbrauchbar machen:
- Selbst, wenn Deine erstgenannten Zahlen stimmen, hast Du die max. Paragraphs / Document überschritten
- Angesichts der Tatsache, dass nicht nur Zeichen, sondern auch Formatierungen, Paragraphs und -styles in die erlaubte Menge von RichText eingehen, könntest Du schon unter der Voraussetzung der erstgenannten Zahlen das Maximum überschritten haben. Auf jeden Fall ist dies aber so, wenn Deine zweitgenannte Zahl (72 Kopien des Eintrags) zugrunde gelegt wird.
Unbeschadet dessen gilt das von Ulrich gepostete: Nach dem Kopieren ist das Dokument im Eimer, ein (unmöglicher) Abbruch und das Verhindern von QuerySave und QueryClose würde nichts mehr ändern. M.E. ist eine Reaktion auf einen ErrorStatus nicht mehr zielführend (lasse mich da aber gerne eines anderen belehren).
Bernhard
-
Die ist nichts besonderes, aber es gibt ein RichText-Feld indem alles was zu dem Projekt getan wird von MA zu dokumentieren ist.
ohne klugscheissen zu wollen, aber das ist das eigentliche Problem.
Das interne Duplizieren von RTF ist grundsätzlich so auch gewollt, weil auch RTF items nicht unendlich Inhalt aufnehmen können.
Und da ist dann irgendwann einmal Schluss.
Die 32k Meldung ist im Übrigen irreführend. Bei Namensfeldern erscheint die auch, wenn das item nur 15k Daten enthält.
Und da wird Bernhard Recht haben. Die schiere Summe aller beteiligten Komponenten erzeugt den Fehler.
Ich würde immer mit untergeordneten Dokumenten arbeiten. Dann ist auch der Datenverlust nicht so hoch.
-
Uhoh.... Feld- und Dokumentengrößen. DAS ist immer so ein Ding. Interessent. Ein paar Anmerkungen:
Bei mir kommt "Dokument hat zuviele Absätze - es muss in mehrere Dokumente aufgeteilt werden.", wenn das Dokument zuviele Absätze hat.
Ich habe mir Lorem Ipsum Texte mit jeweils 65000 Zeichen generieren lassen und wechselnder Anzahl Absätze. Diesen habe ich dann immer wieder kopiert. Den o.g. "Absatz"-Fehler kann ich recht schnell produzieren, aber ein RTF-Feld mit knapp 12MB (ca. 190 Kopiervorgänge) läßt sich ohne Probleme speichern. Dauert halt nur ein bischen ;)
NUR am RichText Item sollte es nicht liegen bei dieser Datenmenge.
Tip:
Guck Dir das Dokument doch mal im ScanEZ (Ytria) an. Und dann sortier die Items nach Summary-Flag und addiere die Größen. Vielleicht ergibt sich ja da schon was.
Empfehlung:
Treib den Nutzern diese lustige Idee, 30+ Seiten RichText ständig per Copy&Paste zu duplizieren, aus. Das mag ja spaßig sein für einen Aprilscherz, aber im täglichen Leben möchte ich den sehen, der damit - selbst wenn es technisch funktionieren würde - klarkommt.
Und dann bau sowas wie "ein Protokoll - ein Dokument" in Deine DB ein (eknori war schneller ::)). Zur Not lass Dir was einfallen, die Menge des eingegeben Textes bzw. die Größe des RichText Feldes sinnvoll zu begrenzen.
Viel Erfolg!
Th.
-
Als erstes möchte bei ich Euch für die Hilfe bedanken.
Ich hab verstanden, dass hier der Fehler von mehreren Faktoren wie Zeichen, Absätze etc. abhängig ist. Leider kann ich nicht wie von meiner Geschäftsleitung gewünscht den Fehler abfangen.
Da Sie aber auf das kopieren nicht verzichten wollen, wird jetzt ein Dokument für jeden Monat im Jahr angelegt und dort können sie dann ihren Abschnitte rein kopieren.
Da im alten Dokument der Abschnitt erst 12 x kopiert werden musste um die Grenze zu erreichen, werden wohl 4 kopierte Abschnitte pro Monat nichts ausmachen.
Ich werde aber die Idee von eknori aufgreifen und versuchen die DB und die dort gespeicherten Projekte auf Antwortdokumente umzubauen.
Wird zwar nicht einfach und ne Menge Arbeit für mich, aber schon wegen dem Thema "Datenverlust" sollte es sich rentieren. :P
Also vielen Dank Euch allen.