This content has been marked as final. Show 10 replies
The solution depends on what you want to do with the selected rows. I normally end up doing a virtual select all, meaning that I set a flag which gets interpreted in method (in the application module or the vo) and the method acts on all rows.
If you like you can select all visible rows to make the user believe that all rows ares selected.
Also note that if you are planning to do an operation on each of the records in your middleware you should probably set the VO tuning access mode to use a forward only cursor:
Thanks Timo for the reply, our applications has all most all tables with multiselect and CTRL + A works for all, and operations depends, user can select all and delete, export programmatically, loop through each selected row to find something, so i am wondering how can we do it.
i am not clear on this. Please can you give an example.
I normally end up doing a virtual select all, meaning that I set a flag which gets interpreted in method (in the application module or the vo) and the method acts on all rows.
and i am also not clean, how can we do select all visible row.
Thank you so much.
Thanks Shay for the reply, our application has multi-select on all tables and CTRL +A works for all of them, so i am wondering if i can do forward access for all VO, because almost all application uses table to show this VO, how does it helps or how can i achieve in such case.
Thank you so much
Note that the forward only thing is recommended for situation where you sequentially go over the rows in a VO one-by-one, I'm not sure if this will solve your UI issue - it is more oriented towards any processing you are doing on the VO in your Java code.1 person found this helpful
In 126.96.36.199 there is an option to disable select all on the table to prevent cases like yours.
Just to clarify - do you see the crash when you actually do ctrl+a in the browser, or is the crash only happening while you are trying to process the rows in some code in your backing bean or VO?
As far as I can see in 188.8.131.52 it doesn't look like pressing ctrl+a actually fetches all the records to the table - so I don't believe you'll crash there.
So assuming you are crashing while actually running some Java code on all of those rows - I guess that using the scrollforward will keep the number of records actually held to minimum.
Thanks Shay for the reply, you are right about CTRL + A won't crash but while iterating it crashes.
I have say 2 million rows of data in the af:table... ( i have used range paging, so it seems at least ok, since my server is not crashing while scrolling to the end of the table ) and i have multi-selection option, so user might do select all, if luckily user does CTRL A , i am good, i will use another viewObject instance that has forward only acccess and i can do anything in fews seconds , BUT, if users does, CTRL A and unselect one or more rows and hit delete , how do i know which are the one user didn't select and do operation on this .. Any help on this
Are you really expecting your end user to scroll through 2M records to find a few records that he doesn't want to use?
How long do you expect it take him to find those rows while looking through millions of other rows?
Wouldn't it make more sense to allow the user to define query conditions that will filter the records in the table so he won't have to search through millions of records manually?
I know my question is just weird like me :( ... sorry about that... yes, your suggestions makes sense... i will for sure have view criteria, but here is the thing.
For sure testing team will do CTRL + A and unselect top fews rows and do the operation. And if the tester can do, user can do at some point, so just wondering, if there is some way i can track out the unselected rows and keep in the list , and don't perform any operation but not on the list, that contains the unselected rows.