Domino 12.0.2FP5 on Windows Server 2022
Notes 6.5.2 on Windows 11
An oldie but a goodie - the 32KB limit
In a large database (>1 million documents) we have a couple of documents that have just started showing the error “Field is too large (32KB)…”
- The error is triggered by a uidoc.save in the PostOpen event.
- Refreshing the document (either in the UI using F9 or via an agent with @Command([ToolsRefreshSelectedDocs]) does NOT trigger the error.
- No individual field is > 32KB
- The total of summary data in the document is < 64KB (actually a bit under 60KB)
- There are no lookups being done by fields that might break the limit - refeshing all fields does not trigger the error, and in fact removing all fields from the form, but still doing a uidoc.save in PostOpen, still does trigger it.
- There are two quite large fields, although both well under 32KB. Setting them to non-summary has no effect.
What exactly might be causing the error?
If LargeSummary is set on the database the error goes away for 12.0.2FP5 users, but not of course for 6.5.2 users. Upgrading of clients is planned, but is not an immediately available workaround.
Hi Andrew,
Try enabling “Large Summary” on the database and see if that helps.
To enable the large summary on the database run the below command.
load compact -ls on database.nsf
Thank you
Regards
Shrikant J
Hi Shrikant.
As noted above, I have tried setting LargeSummary. It is not a solution for me because of the presence of 6.5 clients. Hence I want to understand what is causing the error in the first place.
Pointing out the obvious…Notes 6.5.x does not work correctly on Windows 10, let alone Windows 11. It was developed for Windows 7 and Windows XP.
HCL doesn’t support Notes 6 at all. It is interesting that the organization was able to upgrade the operating system the people are using and then go out of their way to install an obsolete version of Notes instead of installing a supported version of the Notes client.
You can discuss why the 32K limit is being raised in a Notes 6.5.x client using an app on a Domino 12.0.x server but you already know that a supported version of Notes (i.e. 12.0.2) works fine.
Even if you figured out a solution to stop this error in Notes 6, should you continue to allow this obsolete and insecure software to be executed on the organization’s hardware?
Notes 6.5.2 was release in early 2004. This software is 21 years old. The last maintenance release of the 6.5 code stream was in 2006.
1 Like
Your various statements of the obvious would be why we are in the process of moving the client to 12.0.2. They did not, of course, go out of their way to install an old version - they just never got around to upgrading it.
In the meantime, though, we have a problem with 6.5 clients that I am seeking help with.
By the way, you must not confuse “is not certified for…” with “does not work on…”
Notes 6.5 works just fine on later versions of Windows, but for obvious reasons is not formally certified to do so. And Notes, insecure? Please.
The 64KB limit is not the same as the field summary limit. Normally aprox 300 -500 values is allowed I usually see this limit when a fields total size is larger than 16kb. So check if any other field has more than 16kb of data. And remove summary of them, you need to remove the summary in the backend document and save the backend not the frontend doc.
@ ShrikantHCLSoftware, My experience with this is that it does not work on the client side, only when modifying documents in the back end.
Even then it’s unreliable. We’ve ended up saving text greater than 64kb in MIME fields using the NotesMIMEEntity class.
I didn’t mean to upset anyone. As I said, I was pointing out the obvious, mainly for anyone else that might see this thread. No one should be using Notes 6 any longer.
Notes 6 is much less secure than Notes 14.5, but still more secure than anything else that was installed on people’s computers in the early 2000’s.
I have dealt with the 32K limit and usually I can get it pin-pointed to specific field on a document. Then I can write an agent to remove some data from the field to get it to work again (in a copy of the document).
If you remove all the fields form a form and attempt to save a document, you will still hit the 32k issue.
I think ultimately, Notes 6 had more limitations and there are issues with a modern database and a more current ODS on the server versus a Notes 6 client trying to update the server app. I wish I had a solution for you but I think I would do trial-and-error until I found a fix, if these is any fix to be found. I’d make a local copy with no docs in it and copy the docs that are a problem to the local database on the Notes 6 client’s workspace and see if I can reproduce the error. Pay attention to the ODS of the app.
good luck