#dominoforever | Product Ideas Portal

 

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Remove 32k limit for text-fields

Alternatively, implement a feature to dynamlically "extend" these fields (e.g. create an 2nd, 3rd etc. internal field which keeps values exceeding 32k)

Please ;-)

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jul 16 2018
  • Likely to implement
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    19 Dec, 2019 03:03am

    With the large summary support introduced in 9.0.1 FP8, the total size limit of the $field field was increased from 32k to 64k. Maybe whatever was done for that field could be applied to all other text fields without a complete platform overhaul.  It’s still just 64k but as they say... only 2 beers is still better than just 1 beer.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    4 Jun, 2019 02:20am

    There are 32KB limit and prompt info when the To/CC/Bcc field contain one server group with the whole company users, So customer failed to sent mail to the group and got the prompt info as "Field is too large (32K) or View's column & selection formulas are too large"

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    22 Apr, 2019 12:26pm

    II

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    22 Apr, 2019 12:25pm

    Not a big fan of the alternate solution, as that might impact lotusscript operations on fields

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    8 Apr, 2019 02:17pm

    You can go over 32k on a Text Field. You need to flag it as not "is summary"

    But then, you can't display it in a view.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Feb, 2019 05:57pm

    Add the

    Maximum size of a single paragraph in a rich text field

    64KB

    Maximum amount of text (Summary) data per document

    64KB

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    7 Feb, 2019 09:22pm

    I suppose that the difficulties are related to the dimension of the Array and the data type Integer. To increase, you need a new data type...

    Least -
    Please, make an overflow error occur already when adding (NotesDocument.ReplaceItemValue, NotesItem.AppendToTextList), and not when saving. Saving sometimes happens without errors, but the document cannot be opened because it is damaged.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    29 Jan, 2019 08:13am

    Von: "IBM Domino (Thomas Hampel)"

    An:
    Datum: 28.01.2019 16:38
    Betreff: Remove 32k limit for text-fields status has changed to
    Investigating

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    29 Jan, 2019 06:11am

    this is very important. rich text is not useful. but 32k is very small. if indexing or other things not feasible maybe you can create new data type.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    3 Oct, 2018 09:02pm

    My guess is that removing this limit would break other parts of the system which is why it has remained.  I have requested a new field type of JSON, or even better, a new doc/form type that supports JSON.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    26 Sep, 2018 07:46pm

    To the last poster suggesting RT - this can work for a lot of TEXT, but when you have a large TEXT LIST or DATETIME LIST or NUMBER LIST etc. you have to jump through all sorts of hoops to store/retrieve that data from an RT item.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    2 Sep, 2018 11:28am

    If you have a lot of data, you should store it in a RichText item. You can access the data a plain text with RichTextItem.getUnformattedText. Old limit on summary data on the document has been removed -> https://www.ibm.com/support/knowledgecenter/bs/SSKTMJ_9.0.1/admin/admn_increase_document_summary_data_limit.html

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    8 Aug, 2018 08:15am

    If it would be easy to remove the 32KB limit it probably would have been done many years ago. Maybe a better idea would be a new field type like https://domino.ideas.aha.io/ideas/DOMINO-I-80

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    17 Jul, 2018 07:41am

    I agree with the given suggestion to add the field name in the error message.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Jul, 2018 01:26pm

    Suggest to add the field name in the error message. Helps if more number of txt fields with more data

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Jul, 2018 08:00am

    Yeah, you're propably right - I just wanted to place this issue. But any improvement will be appreciated :-)

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Jul, 2018 05:42am

    Not a big fan of the alternate solution, as that might impact lotusscript operations on fields