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
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
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.
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"
II
Not a big fan of the alternate solution, as that might impact lotusscript operations on fields
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.
Add the
Maximum size of a single paragraph in a rich text field
64KB
Maximum amount of text (Summary) data per document
64KB
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.
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.
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.
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.
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
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
I agree with the given suggestion to add the field name in the error message.
Suggest to add the field name in the error message. Helps if more number of txt fields with more data
Yeah, you're propably right - I just wanted to place this issue. But any improvement will be appreciated :-)
Not a big fan of the alternate solution, as that might impact lotusscript operations on fields