Größenbeschränkung für Felder umgehen

[oson00]

Hallo,

ich knobele gerade an einem Problem. Ich möchte ein Feld in einer Maske haben, welches ich mit einer Liste von Namen fülle. Dieses Feld soll auch noch weiterhin ganz normal editierbar sein. Zur Zeit handelt es sich um ein gewöhnliches Namensfeld. In der Praxis ist es nun schon vorgekommen, dass das Feld mehr als 16K aufnehmen sollte und wurde dadurch gesprengt.

Hat jemand eine Idee, wie ich diese Größenbeschränkung umgehen könnte. Ich möchte niht mit mehreren Feldern arbeiten, sondern es soll sich nur um ein editierbares Feld handeln!

[Glombi]

Wie soll man eine Größénbeschränkung von Notes "umgehen" 

Für Deinen Fall kannst Du höchsten noch ein Rich Text Feld nehmen. Es kommt natürlich noch darauf an, was Du so alles mit dem Feld treiben willst.

Andreas

[oson00]

Es ist mir klar, dass sich die Größenbeschränkung nicht ausschalten läßt. Wäre ja zu einfach! ;-)

Aber vielleicht hat ja schon jemand Erfahrung mit der Programmierung von Mehrfachwerten in RT-Feldern o.ä.

[koehlerbv]

Mehrfachwerte und RT-Felder sind nicht zu vereinigen. Du musst sicherlich die Architektur Deiner Applikation umbauen.

Bernhard

[Glombi]

Was soll denn mit den Namen geschehen, die in dem Feld stehen?

[oson00]

Die sollen dann in ein Leser-Feld geschrieben werden. Wenn da allerdings mehr als 16K reingeschrieben werden müßten, wird ein weiteres Leser-Feld erzeugt, welches mit den restlichen Inhalt gefüllt wird usw.

Problem ist nur, dass ich das mit dem Quellfeld nicht machen kann, da dieses schließlich editierbar bleiben soll. Daher dachte ich an eine simulierte Mehrfachwerteeingabe in einem RT-Feld.

[Semeaphoros]

Wie soll ein normaler Mensch noch fähig sein, ein Feld, in dem Namen mit einer Gesamtlänge von 16K drin stehen, dieses sinnvoll zu editieren?

[oson00]

durch suchen...

ihr haltet mich vielleicht für blöd, aber da könnte beispielsweise eine Gruppe rein, die dann in Ihre Mitglieder aufgelöst werden soll.

[Semeaphoros]

Und genau das braucht ja nicht sichtbar zu passieren, kein Problem sowas dann in mehrere Felder zu verteilen ... oder? Wobei die Gruppenauflösung auch schon wieder einen ganzen Bausch von Problemen wirft, jedenfalls läuft man da in eine katastrophale Plegeaufgabe rein

[koehlerbv]

Wozu sollen die Gruppen überhaupt aufgelöst werden ? Der Sinn des ganzen Unterfangens erschliesst sich noch nicht für mich.

Bernhard

[Semeaphoros]

Nicht nur nicht sinnvoll, sondern ohne zwingenden Grund geradezu fahrlässig, um meine vorher etwas versteckte Aussage hier noch zu verstärken

[koehlerbv]

Jo, das zieht ja zumindest die periodische Aktualisierung eines solchen "aufgelösten" Feldes nach sich, es sei denn, man wolle speichern, wer am DD.MM.YYYY Mitglied einer Gruppe war 

Bernhard

[oson00]

Ja, diese periodische Aktualisierung passiert und ich will speichern wer wann in welcher gruppe war...

[Semeaphoros]

Das gehört aber bestimmt nicht in eine Applikation, sondern in ein User-Management System

[koehlerbv]

Warum sollen die dann in ein Leserfeld ? Warum müssen diese editierbar sein ? Das könnte statt dessen doch tatsächlich in ein RTF geschrieben werden.
Weiterhin Fragen über Fragen ... Ich kann den Zweck immer noch nicht erkennen.

Bernhard

[Glombi]

Ich würde den Weg über eine Dialogbox gehen, mit der man das/die Leserfelder setzt.
Dort kannst Du ja Buttons Hinzufügen und Löschen anbieten.

Abgesehen von der Logik insgesamt die diskussionswürdig ist.

Andreas

[koehlerbv]

Wie hebelst Du denn das Feldlimit auf, nur weil es über eine Dialogbox läuft, Andreas ?

Bernhard

[ascom40]

Hallo @All,

Wie soll man eine Größénbeschränkung von Notes "umgehen"

widerspreche ungern, aber wage trotzdem mal zu behaupten, dass man das Feldlimit umgehen kann  .

Ich kann mich noch vage an ein Notes 4.6 Projekt erinnern, bei dem in einigen versteckten Feldern genau dieses Limit umgangen werden musste, ohne RTF-Felder zu verwenden.

Versuchs mal grob zu beschreiben, habe die Anwendung im Moment nicht zur Hand. Soweit ich das noch weiss, wird das Limit nur geprüft, wenn das Feldflag "IsSummary" auf True gesetzt ist. Steht das Flag auf FALSE, wie bei RichText der Fall, dann kann der Feldinhalt in Ansichten nicht gezeigt werden aber das macht ja bei so umfangreichen Feldinhalten wohl eh keinen Sinn.

Um das Item zu löschen, einfach das Item greifen und anschließend mit item.IsSummary = FALSE das Flag auf FALSE setzen.

Bsp.
Set curitem = doc.GetFirstItem(itemName)
curitem.IsSummary = False

Das Flag muss allerdings bei jedem Speichern erneut gelöscht werden, ich glaub, ich habe damals im QuerySave den "normalen" Speichervorgang gestoppt, die Items gegriffen, Flag gelöscht und anschließend im Script das Doc gespeichert, da ist irgendwas komisch gelaufen.

Falls du damit nicht weiterkommst, müsste ich mal auf ner anderen Kiste auf Suche machen, ob ich das Script von damals noch finde, aber kannst ja mal rumexperimentieren.

Jo

[Glombi]

Das stimmt: Die Grenze gilt nur für Felder mit dem Flag "SUMMARY".

Ich kann mich jedoch erinnern, dass es eine Fehlermeldung gibt - siehe auch KBASE:

If a single non-rich text item is bigger than 15360 bytes, the Field Flags value will not be SUMMARY and Notes will not store the field's contents in the summary buffer.  Saving this document results in the warning message "Field 'FieldName' contains too many characters (x over the 15360 maximum).  Field will be saved but will not be displayed in views."  If you reach the limit and try to close the document by not saving the new info, the error still occurs and does not allow the "no save" operation to complete.  The form cannot be exited once the limit is reached.

Aber einen Versuch wäre es natürlich wert.

Andreas

[Glombi]

Wie hebelst Du denn das Feldlimit auf, nur weil es über eine Dialogbox läuft, Andreas ?

Bernhard

Gar nicht. Ich habe nur einen Weg gezeigt, wie er das Leserfeld setzen kann, ohne dass er zuvor in einem Feld, welches alle Namen als Liste enthält, die Namen zuordnet und dann irgendwann über die zulässige Feldgrenze kommt.

Andreas