Interactive Report Returns Misleading Data Because of ROWNUM Limit

Question

Hi, We have been relying on widespread use of Interactive Reports for internal Business Intelligence in our company, and they have been very popular. However, a user found a data discrepancy when sorting a report because the ROWNUM limit of :APXWS_MAX_ROW_CNT is applied before the user requested ORDER BY clause. We are running Apex version 3.2.0.00.27 on a 10.2.0.4 database.
The IR query returns quotes from our custom quoting application, and the default number of rows is 100 (and is changeable by the user). The user wanted to see the most recent quotes, so he selected the "Creation Date" column header and simply applied a descending filter. The most recent quote returned was dated last week. However, if he applied an additional filter of "creation date in the last week", he did see today's date and mostly current quote rows.
When I ran debug on his IR query, I can see that the ROWNUM limit is applied first, then the ORDER BY. This means that the database fetches the first x rows that match the supplied parameters, and then orders the result set. However, this is not what the user meant, he wanted the first rows of an ordered set.
Here's the debug query output (with the middle removed because it's long):
select
       "QUOTE_NUMBER",
       "CUSTOMER",
       "CUST_CONTACT",
       "QUOTE_STATUS",
       "TOTAL_PRICE",
       "TOTAL_WEIGHT",
       "WHSE",
       "SHIP_DATE",
       "PO_NUMBER",
       "ORACLE_REFERENCE",
       "INSIDE_SALESREP",
       "OUTSIDE_SALESREP",
       "CREATION_DATE",
       "ID",
       "ORA_CUST_ID",
       "CUST_CONTACT_ID",
       count(*) over () as apxws_row_cnt
from (
select  *  from (
SELECT
  kh.id,
  kh.ora_cust_id,
  kh.quote_number quote_number ,
  kh.cust_contact_id,
  k2_customers_pkg.get_contact(cust_contact_id) cust_contact ,
  k2_customers_pkg.get_cust_name(kh.ora_cust_id)customer,
  k2_customers_pkg.get_cust_number(ora_cust_id)
( ......... more sql goes here )
AND k2_customers_pkg.get_outside_salesrep_number(kh.ora_site_id)||'%' LIKE :P64_OUTSIDE_SALES||'%'
AND kh.whse_code like :P64_WAREHOUSES||'%'
AND ((1=
    CASE WHEN :P64_ITEM_ID IS NULL THEN
        1
    ELSE
        (SELECT 1
           FROM k2_quote_lines kl
           JOIN k2_ingredients ki
             ON ki.quote_line_id=kl.id
          WHERE (1=1
            AND kh.id=kl.quote_id
            AND ki.ora_item_id=:P64_ITEM_ID AND ROWNUM=1))
    END)
    OR 1=(
        SELECT 1 FROM k2_quote_lines kl WHERE kl.quote_id=kh.id AND kl.part_id=:P64_ITEM_ID AND ROWNUM=1
)  r
) r where rownum <= to_number(:APXWS_MAX_ROW_CNT)
order by "CREATION_DATE" DESC,"QUOTE_NUMBER" DESCHowever, what the user wanted is to have the ORDER BY applied first, then the limit. I realize performance may suffer, but users are now alarmed that they cannot trust these reports. I'm tempted to log a SR with Oracle on this.
Any thoughts on this? Is this fixed in 4.0?
Thank you, Wolf Moritz

Answer 1

Hi, thanks for the response. I did spend a bit of time on trying to trick the interactive report into reversing the rownum and order by clauses. But ultimately I didn't see how to do it. Whatever query I paste into the source of the report is then wrapped in a couple of containing select statements which first applies the rownum limit and then the order by clause (if the user selects any columns to sort by).
So this query:
select * from scott.empBecomes:
select
       "EMPNO",
       "ENAME",
       "JOB",
       "MGR",
       "HIREDATE",
       "SAL",
       "COMM",
       "DEPTNO",
       count(*) over () as apxws_row_cnt
from (
select  *  from (
select * from scott.emp
)  r
) r where rownum <= to_number(:APXWS_MAX_ROW_CNT)
pAnd a user applied sort becomes:
select
       "EMPNO",
       "ENAME",
       "JOB",
       "MGR",
       "HIREDATE",
       "SAL",
       "COMM",
       "DEPTNO",
       count(*) over () as apxws_row_cnt
from (
select  *  from (
select * from scott.emp
)  r
) r where rownum <= to_number(:APXWS_MAX_ROW_CNT)
order by "DEPTNO" DESCIf I could somehow bind to some item for the order by string I might then be able to trick the report into ordering the result set first (which I know can't really be done unless using dynamic sql). Forcing an initial hard coded order by isn't practical on this particular report, although I do see why that might work in some circumstances.
Side note on the oddly placed case statement: This interactive report has some page level "meta" parameter items, and that case statement was meant as a way to avoid an exists statement on a particularly large table if no value was submitted for P64_ITEM_ID. It's been a long time since we deployed the report, so it's probably worth testing some explain/autotrace plans on this case statement vs an exists statement in the predicate. But for now it works!
Thanks, Wolf