Skip to Main Content
HCL Domino 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

856 VOTE
Status Shipped
Workspace Domino Designer
Created by Guest
Created on Jul 16, 2018

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 ;-)

  • Attach files
  • Guest
    Reply
    |
    Jul 29, 2022

    We are delivering this piecemeal - 12.0.2 will see backend classes support large lists and long fields. After that, the rest of the product will follow suit. Please keep the focus on. Thanks, John Curtis

  • Guest
    Reply
    |
    Dec 19, 2019

    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.

  • Guest
    Reply
    |
    Jun 4, 2019

    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"

  • Guest
    Reply
    |
    Apr 22, 2019

    II

  • Guest
    Reply
    |
    Apr 22, 2019

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

  • Guest
    Reply
    |
    Apr 8, 2019

    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.

  • Guest
    Reply
    |
    Feb 20, 2019

    Add the

    Maximum size of a single paragraph in a rich text field

    64KB

    Maximum amount of text (Summary) data per document

    64KB

  • Guest
    Reply
    |
    Feb 7, 2019

    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.

  • Guest
    Reply
    |
    Jan 29, 2019

    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.

  • Guest
    Reply
    |
    Oct 3, 2018

    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.

  • Guest
    Reply
    |
    Sep 26, 2018

    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.

  • Guest
    Reply
    |
    Sep 2, 2018

    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

  • Guest
    Reply
    |
    Aug 8, 2018

    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

  • Guest
    Reply
    |
    Jul 17, 2018

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

  • Guest
    Reply
    |
    Jul 16, 2018

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

  • Guest
    Reply
    |
    Jul 16, 2018

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

  • Guest
    Reply
    |
    Jul 16, 2018

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