Welcome to the #dominoforever Product Ideas Lab! 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 jointly by the IBM & 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
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 16, 2018 05:42

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

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

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 16, 2018 13:26

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

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

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

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

    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
    September 2, 2018 11:28

    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
    September 26, 2018 19:46

    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
    October 3, 2018 21:02

    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.