Hi,
we recently had a problem where we have a document where we store a list of members that opted-in for some functionality. To store this we use Multinode Tree Picker property with Member selection:
When the amount of members exceeded cca 2500 the backoffice failed to load the data while opening this document.
The error message contains this:
"data":{"ExceptionMessage":"This SqlTransaction has completed; it is no longer usable.","ExceptionType":null,"StackTrace":null},"status":500,"xhrStatus":"complete"}
Is there a limit how many items can be selected ? Would there be any other property type more suitable for this scenario?
Hi Gregor,
There is no hard “MultiNodeTreePicker max items” limit unless you explicitly set maxNumber in the data type configuration.
What does happen is that when the editor loads selected members, the backoffice requests item details in batches of 40 IDs, and for ~2500 selections that becomes ~63 parallel API calls. So your 500 (This SqlTransaction has completed; it is no longer usable) looks more like a runtime/scalability issue under heavy parallel loading, not a fixed picker cap.
For this scenario (thousands of members), MNTP is not ideal as primary storage:
-
better use a dedicated model (custom table/repository) or
-
store a rule/group/query and resolve members dynamically,
-
or at least avoid keeping very large selections directly in one picker value.
Best,
/Bishal
1 Like
Hi @gregor-tusar-sowa,
As @BishalTimalsina12, I think you’ve hit some database limit rather than a picker limit as the MNTP was probably not intended to contain that many items. You could create a custom picker that loads the entries more efficiently using pagination but with the same values stored in the database. Alternatively, you could flip it around so instead of storing thousands of members against a content node, store the content nodes against the member individually.
Justin
2 Likes
