Perils of the 50 column collection limit and 100 column page limits.
746040Feb 8 2010 — edited Feb 9 2010Hi All,
You comments and advice would be much appreciated.
Does anybody know if there are plans with APEX 4.0 to alter the 50 column collection limit and/or the 100 column page limit? This has become a stumbling block to our use of Apex for UI requirements.
Before someone tells me that it is bad design to have large numbers of columns (>100) on a page, the reality is that we have many tables exceeding 100 columns. Users need the ability to filter data from these tables by way of an interactive report linked to a form where they can edit individual cell values displayed on the form, and submit the updates. The 100 column limit prevents this.
To avoid the clutter of a 100+ columns being displayed simultaneously the aesthetics can be improved by use of Hide and Show Regions for groupings of like columns.
I have decided that the forms need to be used for ad-hoc updates only, and not for new record creation, however the 100 column limit means that even this is not feasible. I have thought of using a custom update procedure based on updating only changed* item values which should usually be less than 100 per record. Any ideas on how to do this efficiently??
Creating new records via large forms is not desirable as users are likely to revolt at filling in anything like 100 items on a form. (I did experiment with a wizard approach involving an insert of mandatory fields on the first page followed by a series of updates to the newly created record, on subsequent wizard pages, but I considered this to be too messy, involved and confusing for the user.
I decided the a better solution for new records was to do all inserts into these large tables via delimited file (csv's) uploads. With help from previous forum articles, I managed to create a working, generic, table loading tool. Then I ran into the *50 column collection limit*.
My solution will now have to involve the use of external tables and database stored procedures for processing the data loads, hopefully via an Apex interface. In one application alone this will mean 17 external tables and associated load procedures plus more complex maintenance, troubleshooting and training. All of this would be far simpler without the hard limits on columns.
Cheers,
Meagain