Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: Bruce Willis am 25.04.06 - 11:41:36
-
Hallo,
in einem Text-Feld eines einfachen Dokuments erscheint anstatt vom Text die Fehlremeldung:
FEHLER: Feld ist zu groß (32K), oder die Spalten- oder Auswahlformeln der Ansicht sind zu groß
1. Kann ich auf die Daten im Feld irgendwie (ohne Backup) kommen?
Oder sind sie verloren?
2. Benutzt jemand etwas, um solche Fehler in Text-Feldern zu vermeiden?
Danke und Gruß
Leo
-
Hallo Leo,
ich bin mir nicht ganz sicher, aber ich glaub ich hatte ähnliches Prob vor einiger Zeit. Bei mir hat es
gereicht die Ansicht (oder auch alle) neu aufbauen/aktualisieren zu lassen (halt "STRG" und "Shift" gedrückt und drücke "F9" wenn du dich in der DB befindest).
Gruß
Volker
-
Falls der Vorschlag von Volker nicht klappt, probiers mal mit Code und @Abbreviate o.ä.
Was ich hier wieder nicht an Notes begreife ist, wie kann ich in ein Feld mehr hineinschreiben als es Platz hat? Und wieso wird das nicht abgefangen?
Grüsse
Moritz
-
Über die Dokumenteigenschaften solltest Du noch an den Inhalt herankommen - zumindest an den Teil bis zur 32k Grenze.
Es kann aber auch sein, dass es ein zur Anzeige berechnetes Feld ist, welches den Inhalt per @DbLookup bekommt oder ein Schlüsselwortdokument mit einem @DbLookup aus Auswahlformel.
Was ist es denn?
Ich glaube, man kann per Script die Property "IsSummary" auf false setzen, damit der Fehler zumindest in Ansichten nicht auftritt. Dazu gibt es hier im Forum ein paar Threads.
Andreas
-
halt "STRG" und "Shift" gedrückt und drücke "F9" wenn du dich in der DB befindest
Hallo Volker,
danke, hat leider nicht geholfen.
Gruß
Leo
-
Falls der Vorschlag von Volker nicht klappt, probiers mal mit Code und @Abbreviate o.ä.
Danke, Moritz.
Gute Idee, ich werde's probieren.
-
Über die Dokumenteigenschaften solltest Du noch an den Inhalt herankommen - zumindest an den Teil bis zur 32k Grenze.
Nein, das habe ich schon probiert.
Dort wird die gleiche Fehlermeldung angezeigt.
Es kann aber auch sein, dass es ein zur Anzeige berechnetes Feld ist, welches den Inhalt per @DbLookup bekommt oder ein Schlüsselwortdokument mit einem @DbLookup aus Auswahlformel.
Was ist es denn?
Wie gesagt, ganz normales Text-Feld, das man direkt bearbeiten kann.
Ich glaube, man kann per Script die Property "IsSummary" auf false setzen, damit der Fehler zumindest in Ansichten nicht auftritt. Dazu gibt es hier im Forum ein paar Threads.
Danke, Andreas,
es geht aber leider nicht um Ansichten.
-
Wenn es nur ein ganz einfaches Textfeld ist, das NUR durch manuelle Eingabe gesetzt wird, dann hat wahrscheinlich jemand den Text "FEHLER: Feld ist zu groß (32K), oder die Spalten- oder Auswahlformeln der Ansicht sind zu groß" dort hereingeschrieben.
Andreas
-
Falls der Vorschlag von Volker nicht klappt, probiers mal mit Code und @Abbreviate o.ä.
Danke, Moritz.
Gute Idee, ich werde's probieren.
Hat leider nichts gebracht. :'(
Das neue Feld mit der u.g. Formel zeigt nur die besagte Fehlermeldung! ::) :'(
@Abstract( [TextOnly];8000 ;""; "ProblemFeld")
-
Wenn es nur ein ganz einfaches Textfeld ist, das NUR durch manuelle Eingabe gesetzt wird, dann hat wahrscheinlich jemand den Text "FEHLER: Feld ist zu groß (32K), oder die Spalten- oder Auswahlformeln der Ansicht sind zu groß" dort hereingeschrieben.
Andreas
Das kann aus bestimmten Gründen nicht der Fall sein... ;)
-
Also wenn in den Dokumenteigenschaften auch nur der Fehlertext steht, dann hast Du keine Chance mehr an den urspr�nglichen Text zu kommen.
Diese meldung kann aber eigentlich nur dann da hereinkommen, wenn das Feld von au�en gesetzt wird - per Button/Hotspot/Aktion, per Agent, per Formelsprache bspw. von einem anderen Feld, per Script...
Andreas
-
Das kann aus bestimmten Gründen nicht der Fall sein...
Erklär mal genauer...
-
Das kann aus bestimmten Gründen nicht der Fall sein...
Erklär mal genauer...
Ok, ich hatte bloß gewollt, die Sache einfach zu halten...
Du hast richtig erkannt, das Feld "ProblemFeld" ist in der Tat ein berechnetes Feld, wo alles zusammen gespeichert wird, was man in ein anderes Feld "EingabeFeld" ab und zu einträgt.
Sieht in Querysave etwa so aus:
@If(EingabeFeld="";@Return("");@Success);
FIELD ProblemFeld:= @Text(@Now;"D0T1") +" -- "+ @Name([CN];@UserName) + @NewLine+ @NewLine+ EingabeFeld+ @NewLine +
"__________________________________________________"
+ @NewLine + @NewLine+ ProblemFeld;
FIELD EingabeFeld:= "";
Ich dachte, dass hier diese Einzelheiten ohne Bedeutung sind.
Ist auch so, oder?
Gruß
Leo
-
Aha, warum denn nicht gleich so ;D
Durch die Formel im Querysave wird dafür gesort, dass das Feld "ProblemFeld" irgendwann mal die zulässige Größe von 32K für Textfelder überschreitet, da es immer erweitert wird.
Abhilfe kannst Du erreichen, in dem Du das Feld entweder als RichText Feld deklariert und dann mit neuen Methoden das Rich Text Item setzt oder es als Textfeld lässt, aber nur die letzten N (bspw. 10) Einträge sicherst.
Das geht dann ungeführ so:
@If(EingabeFeld="";@Return("");@Success);
FIELD ProblemFeld:=
@If(@Elements(ProblemFeld) < 11;
@Text(@Now;"D0T1") +" -- "+ @Name([CN];@UserName) + @NewLine+ @NewLine+ EingabeFeld+ @NewLine +
"__________________________________________________"
+ @NewLine + @NewLine+ ProblemFeld;
@Text(@Now;"D0T1") +" -- "+ @Name([CN];@UserName) + @NewLine+ @NewLine+ EingabeFeld+ @NewLine +
"__________________________________________________"
+ @NewLine + @NewLine+ @Subset(ProblemFeld;-10)
);
FIELD EingabeFeld:= "";
Andreas
-
Vielen Dank, Andreas!
Ansonsten
1. keine Möglichkeiten auf die Daten im Feld zu kommen?
2. eine elegante Formel-Lösung, den User beim Speichern des Doks und "ProblemFeld" > 31 K zu warnen?
Gruß
Leo
-
Zu 1. keine Möglichkeiten auf die Daten im Feld zu kommen?
Ich sehe da keine Möglichkeit außer Backup.
Nicht mal ein künstliches Neusetzen mittels $Revisions und $Updatedby ist nicht drin, da variable Werte (EingabeFeld) verwendet werden-
2. eine elegante Formel-Lösung, den User beim Speichern des Doks und "ProblemFeld" > 31 K zu warnen?
Wozu? Soll das Speichern dann verhindert werden?
Ansonsten: Mit @Length(Feldname) kannst Du die Anzahl der Zeichen in einem Feld zählen. Du musst halt ausrechnen, wieviele dann maximal drin stehen dürfen.
Andreas
-
Du kannst prüfen wie groß die einzelnen Felder sind, aus dem sich das "Resultats-Feld" zusammensetzt, nicht wahr?
Du kannst das dann ausrechnen und bei zu großen Werten den Wert des >31k Feldes auf mehrere Felder verteilen (ergebnis, ergebnis_1), etc.
Oder du kommst auf den Trichter, dass du dieses gewaltige Zusammenfass-Feld doch nicht brauchts...
Jedenfalls ist >32k ein Punkt, an dem man oft nicht mehr tricksen kann. Ich bin dem erstmals September 1999 begegnet. Irgendwie ist das auch beruhigend.
-
Vielen Dank an alle! :)
P.S. Vielleicht noch eine Frage:
Ein Buchstabe ist doch ein Byte (nicht ein Bit), stimmt's?
-
Nein - ein Buchstabe sind zwei Byte auf Grund der Notes-internen Codierung, die ja weit über den ASCII-Standard hinausgeht. Plus noch ein wenig Overhead für das Item selbst.
Ich verwende in Routinen, die Textfelder im Backend belegen (LS) eine Grenze von 31.000 Byte und bin damit auf der sicheren Seite. 32.000 Byte ging nicht (zumindest unter R5, nd warum sollte ich wegen popligen 1.000 Byte diese Kompatibilität jetzt aufgeben? ;))
Bernhard
-
Hallo Bernhard,
zwei Byte ???
OK, danke!
Da Du gerade online bist und offensichtlich gute Laune hast, will ich die Gelegenheit völlig ausnutzen. ;)
Und zwar:
1. Sind dann 32 KB = 32 x 1024 = 32.768 B = 32.768 : 2 = 16.384 Buchstaben? ??? Ist doch nicht viel... >:(
2. Warum sprechen wir eigentlich von 32 KB wenn ein Text-Feld angeblich 64 KB vertragen sollte?
Gruß
Leo
-
Da Du gerade online bist und offensichtlich gute Laune hast ...
Ich habe eigentlich immer gute Laune, Leo ;D
Siehe Dir bitte diese Aufstellung an - in der Designer- resp. AdminHelp (vor allem über mehrere Versionen muss man sich das durchaus erstmal zusammensuchen): GeniiSoft: DominoLimits (http://www.geniisoft.com/showcase.nsf/DominoLimits)
HTH,
Bernhard
-
32KB weil halt in der NotesApi:
WORD LNPUBLIC NSFItemGetText(
NOTEHANDLE note_handle,
const char far *item_name,
char far *item_text,
WORD text_len);
text_len als "WORD" Typ in C definiert ist!
und "WORD" folgendermaßen richtigerweise definiert ist:
typedef signed short WORD
d.h die Textlänge ist ein 16-bit Feld mit Vorzeichen (Plus/Minus).
Das erste Bit steht für das Vorzeichen, bleiben 15 Bit übrig.
Das sind 2^15 = 32768 Byte
Also: 32768 / 1024 = 32 KB
Wäre es als UWORD definiert:
typedef unsigned short UWORD
wären es 64KB!
Das ist der Grund! ;D
Jetzt kann man natürlich diskutieren, ob Textfelder auch negative Längen haben können... oder ob hier unsinn gemacht wurde... ???
Gruss
Chris
-
Danke, Chris!
:D
-
Passt schon ich wollt mich halt grad mal auskotzen, dass viele C-Programmiere und viele C-Programme, wild vorzeichen und vorzeichenlose Datentypen durcheinanderwirbeln, was immer wieder zu interessanten Effekten und Beschränkungen führt! :)