Problem in tabular form based on dynamic view and pagination

Question

Hi All,
I have a manual tabular form based on a dynamic view. The view fetches the records based on search criteria given by the user in all cases. But this view fetches ALL records when user clicks on pagination, without considering the search criteria. This is the problem I am facing.
I am doing the following:
Since tabular form does not support pl/sql function returning query, I cannot use a table directly. I need my results based on search criteria selected by user. Hence I created a dynamic view and used a "INSTEAD OF UPDATE" trigger to update the table.
I use a set bind variables procedure, on load before header for setting the variables.
This view fetches the correct data based on user search always. It creates a problem only in one situation, when using pagination in the report.
The example can be found at:
http://apex.oracle.com/pls/otn/f?p=19399:1:
username = [email protected]
pwd = kishore
Here if "manager name" is entered as test, we get 5 records in "Summary of requests" report and 5 records in "Inactive Requests" report. When user clicks on Pagination in any of the reports, ALL the 7 records get fetched in "Summary of Requests" and 6 records in "Inactive Requests". How can I overcome this problem?? The report must consider the search variables even when pagination occurs.
Is this because, the inbuilt "html_PPR_Report_Page" executes the region query once again by considering all search variables as NULL?
Backend Code is at:
http://apex.oracle.com/pls/otn/
workspace: sekhar.nooney
Username :[email protected]
pwd: kishore
application id = 19399
My region code is something like:
select *
from regadm_request_v
where access_type = :F110_REGADM
and status <> 'INACTIVE'
order by request_id
My view code is:
CREATE OR REPLACE VIEW REGADM_REQUEST_V
AS
SELECT *
FROM REGREGOWNER.REGADM_REQUEST
WHERE upper(employee_name) LIKE '%'||nvl(upper(REGADM_REQUEST_PKG.GET_EMPLOYEE_NAME),'%')||'%'
AND upper(manager_name) LIKE '%'||nvl(upper(REGADM_REQUEST_PKG.GET_MANAGER_NAME),'%')||'%'
AND upper(employee_sunetid) LIKE '%'||nvl(upper(REGADM_REQUEST_PKG.GET_EMPLOYEE_SUNET_ID),'%')||'%'
AND upper(manager_sunetid) LIKE '%'||nvl(upper(REGADM_REQUEST_PKG.GET_MANAGER_SUNET_ID),'%')||'%'
AND upper(request_date) LIKE '%'||nvl(upper(REGADM_REQUEST_PKG.GET_REQUEST_DATE),'%')||'%'
AND upper(USAGE_AGREEMENT_RECVD) LIKE '%'||nvl(upper(DECODE(REGADM_REQUEST_PKG.GET_USAGE_AGREMNT_RECVD,'~!@',NULL,REGADM_REQUEST_PKG.GET_USAGE_AGREMNT_RECVD)),'%')||'%'
AND upper(STATUS) LIKE '%'||nvl(upper(DECODE(REGADM_REQUEST_PKG.GET_STATUS,'~!@',NULL,REGADM_REQUEST_PKG.GET_STATUS)),'%')||'%'
AND upper(REQUEST_APPROVED) LIKE '%'||nvl(upper(DECODE(REGADM_REQUEST_PKG.GET_REQUEST_APPROVED,'~!@',NULL,REGADM_REQUEST_PKG.GET_REQUEST_APPROVED)),'%')||'%'
AND upper(nvl(APPROVAL_DATE,sysdate)) LIKE '%'||nvl(upper(REGADM_REQUEST_PKG.GET_APPROVED_DATE),'%')||'%'
AND upper(APRVL_REQUEST_SENT) LIKE '%'||nvl(upper(DECODE(REGADM_REQUEST_PKG.GET_EMAIL_APPROVERS,'~!@',NULL,REGADM_REQUEST_PKG.GET_EMAIL_APPROVERS)),'%')||'%'
AND upper(NOTIFY_APPROVED) LIKE '%'||nvl(upper(DECODE(REGADM_REQUEST_PKG.GET_APPROVAL_NOTIFICATION,'~!@',NULL,REGADM_REQUEST_PKG.GET_APPROVAL_NOTIFICATION)),'%')||'%'
I would be glad for any suggestions.
Andy/Varad any ideas? You both helped me a lot on my problems for the same application that I had faced before in More Problems in Tabular form - Please give me suggestions.
Thanks,
Sumana

Answer 1

Hi Andy,
The view and the package for setting bind variables work properly in my entire application other than the pagination. A pity that I came across this only now :(
I have used this same method for holding variables in another application before, where I needed to print to PDF. I used this approach in the other application because my queries were not within the APEX character limit specified for the "SQL Query of Report Query shared component".
In this application, I initially had to fetch values from 2 tables and update the 2 tables. Updateable form works only with one table right? Hence I had created a view. Later the design got changed to include search and instead of changing the application design I just changed the view then. Still later, my clients merged the 2 tables. Once again I had just changed my view.
Now, I wanted to know if any method was available for the pagination issue (using the view itself). Hence I posted this.
But as you suggested, I think it is better to change the page design quickly (as it would be much easier).
If I change the region query to use the table and the APEX bind parameters in the where clause as:
SELECT *
FROM REGADM_REQUEST
WHERE upper(employee_name) LIKE '%'||nvl(upper(:P1_EMPLOYEE_NAME),'%')||'%' .....
I also changed the ApplyMRU to refer to the table.
Here the pagination issue is resolved. But here the "last Update By" and "Last Update Date" columns do not get updated with "SYSDATE" and "v(APP_USER)" values, when update takes place. Even if I make the columns as readonly text field, I am not sure how I can ensure that SYSDATE and v('APP_uSER') can be passed to the columns. Any way I can ensure this? Please have a look at the issue here: http://apex.oracle.com/pls/otn/f?p=19399:1:
I have currently resolved the "last update" column issue by modifying my view as:
CREATE OR REPLACE VIEW REGADM_REQUEST_V
AS
SELECT *
FROM REGADM_REQUEST
I modified my region query to use APEX bind parameters itself as:
SELECT *
FROM REGADM_REQUEST_V
WHERE upper(employee_name) LIKE '%'||nvl(upper(:P1_EMPLOYEE_NAME),'%')||'%' .....
And I use the "INSTEAD OF UPDATE" trigger that I had initially written for update. The code is:
CREATE OR REPLACE TRIGGER REGADM_REQUEST_UPD_TRG
INSTEAD OF UPDATE
ON REGADM_REQUEST_V
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
UPDATE REGREGOWNER.REGADM_REQUEST
SET MANAGER_EMAIL = :NEW.MANAGER_EMAIL
, EMPLOYEE_EMAIL = :NEW.EMPLOYEE_EMAIL
, STATUS_UPDATE_DATETIME = SYSDATE
, USER_UPDATE_ID = (SELECT v('APP_USER') FROM DUAL)
WHERE REQUEST_ID = :OLD.REQUEST_ID;
END;
Please let me know how I can resolve the "last update" column issue using the table itself. (Just for my learning)
Thanks,
Sumana