Main Region

How can the 32K-limit of shuttles be bypassed?
2 answers | 280 views

JO
Jul 16, 2014 07:15 +00:00

In the shuttle-docu there ist a hint that "Currently this item type has a 32K limit.". And indeed I can only put up to 2000 items in a shuttle (the same for the multiselect-box?).

Problem is, that we have more use cases, where we have up to 5000 items to be handled in a select-and-assign-situation. E.g. more than 5000 users in the system which can be activated for an application, i.e. the admin can assign up to 5000 users to an application - visually represented with a shuttle.

First question: is there a kind of a time schedule or are there plans when the number of items in a shuttle will be higher or at least unlimited?

Second question: do you have any suggestions to circumvent this barrier? Other ways to get a select-and-assign of items done?

regards Jochen

1 comment

MN
Matt Nolan Jul 29, 2014 17:46 +00:00 

You should create a new dynamic action listen to the event "FOEX Grid CRUD Success" to perform your next action after the grid data is processed. e.g. an Execute PLSQL Code action.

We will consider adding an enhancement in the future to give you another hook to run some PLSQL after all rows are processed.

MN
Jul 16, 2014 07:41 +00:00

I can't give any timeline advice to when we will enhance the shuttle as there are many other features that require our attention.

Personally I don't think using a shuttle with 5000 items is user friendly and a good idea. Perhaps you could use a grid with a checkbox column to track selections on top of a view that saves the selections to a temporary table or collection. The benefit is that you will get all the grid features for pagination, searching, sorting showing additional columns etc. You would then use a pre/post processing feature on the form plugin to save the data permanently. A form has layout capabilities and can have child layouts to easily add your grid to it.

0 comments

JO
Jul 29, 2014 13:41 +00:00

Hi Matt,

meanwhile I found some time to implement your suggestion. I implemented a "Processing Procedure Override" which populates a temporary table collecting all check or uncheclk results.

This procedure fires for all rows which have a change in the check box (i.e. which have been selected or unselected). This fires with a save button on the grid (not the form - but maybe I can do this later on. The form contains 2 tabs. One holding the base date of the main object, one holding the grid with the clickable relations)

But: As an After-Process I want to update the original Relation table with all changes. That means, disableling or deleting all unchecked and inserting all checked relations. For performance reasons it's not appropriate to do this as a "Post Processing Procedure" because this fires for every changed row.

When I do it in a DA (button click event) this procedure is executed before the original grid override procedure, which fills the temp table with the click/unclick data.

Question: Where or at which point could I call this post procedure right after the user clicked the save button.

greetings Jochen

0 comments

You must log in or sign up to post questions and answers.