This is a problem quite a number of us have "solved" in different ways - and in different versions of Apex.
The checkboxes in an IR created through apex_item.checkbox2 - when "checked" are not stored in session - a pagination causes a partial page refresh and the HTML is replaced.
You will need to keep track of the checkbox status manually.
John Snyders put together a more up to date example using Apex 5 on his blog - this is one way to do what you are attempting.
Take a look and see if this helps you - and remember to provide more information when asking a question - e.g. which version of Apex!
another approach to preserve checked values nicely described joelkallman-Oracle here Let's Wreck This Together...with Oracle Application Express!: Preserving checked checkboxes in a report . While the requirement and the idea behind is still perfectly valid, the implementation is a bit obsolete, so I tried to reimplement it using current APEX features and dynamic actions.
The underlying report select is
select apex_item.checkbox2(1, empno, 'onclick="$s(''P1_CHECKED_CBOX'',this.value)"',a.c001) cbox, "EMPNO", "ENAME", "JOB", "MGR", "HIREDATE", "SAL", "COMM", "DEPTNO" from "EMP" , apex_collections a where a.c001 (+)= empno and a.collection_name (+)= 'EMP_COLLECTION'
So basically whenever any checkbox is checked, it triggers a DA that saves it's value to the EMP_COLLECTION. The nice thing is that we have a declarative way to run the PL/SQL block asynchronously on the background, so the user does not have to wait until the value is saved (Wait for Result = NO).
Please, see the working example on https://apex.oracle.com/pls/apex
app: Application 105127 - preserve_report_checkbox
I have used Joels version myself many times - updating a collection and using that as an outer join in the select statement
I've also always forced a "synchronous" DA to ensure that updating the collection happens correctly (i.e. duplicate clicks on the same checkbox work as you expect them to... rather than potentially out of sequence)
What do you think about the future (Apex 5.1 and beyond) where the synchronous element of the DA is no longer available by default?
i.e. all DA's will be asynchronous
The way discussed by Joel probably needs amending/tweaking to incorporate this.
I think John Snyder is trying to address this in his post.
I may try to apply John's ideas to the collection version - unless you've already done so and can shed your thoughts on this!
sorry for a bit late response. I'm not that familiar with APEX 5.1 yet because of obvious reasons. So far I've just toyed with APEX 5.1 (https://apexea.oracle.com/ ) and my impressions are that:
1) the new Interactive grid is pretty cool and feature-rich,
2) DAs look same way in the page designer (e.g. there is still the very same Wait for the Result toggle button), so I don't care too much how it's implemented internally.
There is no reason why the method described above should not work also in APEX 5.1 (I haven't tested it yet though), so for me the choice is simple.
Thanks for getting back to me Pavel.
Its the "Wait For Result" bit that interests me as this may change going forward
The following forum post - John Snyders response - made me wonder if we should be catering for the death of the "synchronous" DA in Apex right away to help future proof upgrades.
Plus Johns blog page - APEX and Asynchronous Ajax | HardLikeSoftware
I was just hoping to pick up on a nice way to make things future proof :-D
Currently though, as you said, I agree that the collection version is easiest.
I'm definitely not the one who can make these things clear. From my point of view the Wait for Result toggle button is not going to disappear. I just believe APEX devs do care of the backwards compatibility and if this functionality was removed, lots of apps would start to produce pretty surprising results.
Also if there was no way to keep consecutive true actions in one DA "synchronized" (e.g. run one after another is finished), I would consider it as a serious limitation...in fact it would be IMO broken.