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

Status Under Consideration
Workspace Domino Designer
Created by Guest
Created on Mar 20, 2019

Remove 64k limit for @Dblookup

In addition to restriction for field size, it is necessary to remove shameful restriction for data size, received by dbLookup. I so think! Periodically happens it is impossible to use too much key word in the choice of field values.

  • Attach files
  • Guest
    Reply
    |
    May 21, 2021

    Perhaps you could have a function called @Dblookup2 which would increase 64K limit. Developers could then go into their apps where they know they have considered backward compatibility and just switch to the "2" version of @Dblookup.

  • Guest
    Reply
    |
    Apr 4, 2019

    As a workaround, you can split the data into multiple (CFD) fields and use those in the choices field of the checkbox/radiobutton field. Of course if too much data is selected, you still are stuck

  • Guest
    Reply
    |
    Mar 22, 2019

    I'm reasonably certain they remain in order to provide backward compatibility.  While I think most developers would welcome the removal of the limits, it may negatively impact existing apps that were created expecting those limits.  I had suggested in another idea to add a document type that just supports storing data as JSON and getting rid of types and low limits.