Processing Values When Rendering A Page

Question

Hi,
I have an application that loads a page and retrieves a single row from a table. If one specific column is not null, I have a PL/SQL function call that retrieves related information (via database link) for display. This does not seem to be working when I first render the page; subsequent views of the same page (after applying changes, for example) will show the information properly.
Any suggestions how to make the related data retrieved from the PL/SQL call display on the first rendering of the page?
TIA,
Earl

Answer 1

Scott,
I can communicate the techical problem if I knew precisely what you needed. I just can't send you all the code, which is what you asked for. Anyway, I've embedded comments/responses to your assumptions below, which hopefully clarify the issue so I can get a solution to the problem.
> Let me expand on why troubleshooting your problem
without this information is a waste of time: 1) You
said "if a column in a fetched row is NOT NULL,...".
I can assume that you are using an Automated Row
Fetch process and that you have page items with
Source Type Database Column. But I should not have to
assume that, you should volunteer all such
information.
Yes, I have a single column in a fetched row, gathered using the Automated Row Fetch process. The ARF fetch is based on the table column COW_ID, which is the primary key for the table. The page item P23_COW_ID has source type of Database Column and maps to this specific column in the table.
The page item is called P23_CQAI_NUMBER, with a source type of Database Column. Default type is STATIC_TEXT_WITH_SUBSTITUTIONS, ACCEPT_PROCESSING = REPLACE_EXISTING, and USE_CACHE_BEFORE_DEFAULT = NO. There are no tranlations or post-processing on the field. The ARF happens at sequence #1, before the page is rendered.
2) You said "...call a PL/SQL
procedure..." I can assume that you're using an
on-load page process based on some condition and that
the conditions aren't working and that you've already
determined that the process itself would work if only
the condition worked. But that assumption may be
incorrect.
The following anonymous block PL/SQL is defined as an on-load page process, AFTER_HEADER (tried BEFORE_HEADER, but no difference in behavior). I originally set it to run conditionally (on if P23_CQAI_NUMBER was NOT NULL), but decided to run it unconditionally and embed the not null logic in my PL/SQL block in attempt to debug:
begin
if (:P23_CQAI_NUMBER is not NULL) then
my_package_name.get_cqai_data(p_cqaiID => :P23_CQAI_NUMBER,
p_submitter=>:P23_CQAI_SUBMITTER,
p_assignee=>:P23_CQAI_ASSIGNEE);
end if;
end;
p_submitter and p_assignee parameters in the above procedure call are both VARCHAR2 OUT parameters.
This code always failed, until today in attempt to debug, I changed the block as follows:
declare
l_cqai_number varchar2(8);
begin
select cqai_number into l_cqai_number from my_table
where cow_id = :P23_COW_ID;
if (l_cqai_number is not NULL) then
my_package_name.get_cqai_data(p_cqaiID => l_cqai_number,
p_submitter=>:P23_CQAI_SUBMITTER,
p_assignee=>:P23_CQAI_ASSIGNEE);
end if;
end;
This works every time; but I don't understand why I have to make a second query to the database to get the data already fetched by ARF in sequence #1.
3) I can further assume that you're
referencing the fetched column value using bind
variable or v() notation sometime after the ARF
process runs and that you are using the proper DML
Fetch Mode attribute of the ARF process and that you
are using a version of Application Express that
supports that attribute. You are correct. As far as using the APEX version that supports the attribute; I don't know. I'm using version 1.5.0.00.33 and the documentation is a little thin.
ScottTIA,
Earl