Regular Report Not Returning All Rows
cloakedJan 14 2013 — edited Jan 15 2013Greetings,
On APEX version 4.1.1.00.23 Using latest versions of Chrome and IE. I found some threads that discussed this aspect some, but not to the extent that is helpful to my situation.
I know it is crazy to have APEX return 40K+ rows on a report, but I have a need to do so. I need to return that many rows from a table so that an APEX page can be opened via Excel and then have an Excel macro run over the report results and import all 40K+ rows into a worksheet. As I said, that's crazy, but the decision isn't mine. :-) We have the macro working and it passes parameters to the APEX page and imports data from the APEX page.
Also, the report has 14 columns on it, not that many.
Given the requirement above I have a regular report page that only has the report and 2 page items on it. The page items contain values that are passed via Excel and are then used in the WHERE condition of the report. Using the same WHERE condition, when I run the SQL for the report outside of APEX it returns 46,840 rows. I have the both the Number of Rows and Maximum Row Count settings set to 50000. And, I have the Pagination Scheme set to Row Ranges X to Y of Z (with pagination).
When I run the page and enter the selection criteria the report only returns 15,500 rows. Yes, that's a lot rows. And, it takes about 5 minutes to populate. But, it doesn't return ALL of the rows. Also, the pagination suggests that all rows were returned because it reads - row(s) 1 to 15500 of 15500. I have changed the pagination and max rows settings a lot to see of it's just a matter of having the correct report setting. I've yet to find a setting that will cause the whole 46840 result set to be returned.
It may end up that the report selection needs to change in order to return fewer rows. But, regardless of that why isn't APEX returning the complete result set now? And, is there a way to force it to return the complete result set regardless of the size?
Any suggestions are appreciated.
Thanks, Tony