"no data found" run-time error masking SQL/report mismatch

Question

Hi all,
At last, figured out a vexing problem and wondering if anyone else either:
a) has also hit the problem, and hopefully
b) has figured out a clever way around it.
Namely, in our AppEx apps, we rely on SQL query generation from PL/SQL packaged functions. This "best practice" promotes reuse, automated testing, etc. Great idea - works great.
However, we've repeatedly come across a situation where we go to run a page with a report on it only to get a "report error: ORA-01403: no data found" message where the report should be. Not much to go on. After trial and error, it turns out that simply going to the Region Definition page (where the PL/SQL function call is defined) and clicking the "Apply Changes" button cleared the problem up.
Mystifying because the actual SQL query generated by the PL/SQL is valid (we've got a nightly testing job that pulls the PL/SQL function calls out of the AppEx metadata tables, executes them to get back the SQL and then validates the SQL).
Turns out this problem looks to be a result of columns changing in the actual SQL itself, and hence not matching up to the Region Attributes (column names, one assumes) that AppEx knows about. Simply clicking Apply Changes causes AppEx to validate the returned query and then it adjusts the column attributes (one assumes) so that things match up.
So - the $64,000 question(s):
1) Are there any cool AppEx APIs to be able to try and detect this situation? Given an app of middling complexity (50-100 pages, each with various queries/reports), this is not an attractive issue to deal with manually.
2) Any cool AppEx APIs to fix, or auto-sync these situations? (Essentially programmatically calling the "Apply Changes" button if you will).
At a minimum, it would be great if AppEx could be updated to put out some kind of more informative error message when this occurs - maybe something along the lines of "Region Attributes Do Not Match Data Returned from Query", or something like that at least.
Thanks for any input/ideas,
Jim C.

Answer 1

Thanks to all for your prompt responses.
Vikas actually did me the favor of pretty much clarifying my info for me (tks Vikas). Yes, to all the above. It's PL/SQL code generating a SQL query, so 1 is (a); we want to use query-specific columns so it is (2a). And yes, the whole problem is that the something does change to cause the SELECT statement column list to change...nature of the beast, so "don't do that" doesn't really help here.
Scott - sorry, should have been more explicit. Basically, we have a PL/SQL function behind a report that returns a SQL statement for the report. If that PL/SQL code changes to add a new column to the report (without going to the corresponding Report Attributes page and clicking the "Apply Changes" button to get AppEx to revalidate the query), then you wind up with this "no data found" error msg, which doesn't exactly point you to the root of the problem.
It seems as though the "parse at compile-time" is really what's going on here. There must be some kind of "run-time" check going on as well, that is resulting in the "no data found" message. Seems as though it ought to be fairly straightforward to add some kind of check at run-time to handle that exception a little cleaner. Is there an official process to register a "Request for Process Enhancement" for AppEx to do this?
In the meantime, thank you Vikas for the pointer to the APEX_APPLICATION_PAGE_RPT_COLS view - that looks like it will do the trick nicely. Given that, we can now add logic to our nightly "app tester" job that can compare what columns AppEx expects to find in a given report (for a given page) with the actual SQL (coming back from the PL/SQL function call) to essentially "validate" the AppEx meta data and at least let us know when these things get out of sync.
BTW - if anyone would be interested in the actual contents of that "app tester" logic, I'd be happy to post it (someplace...here? Studio site?). It's basically just a PL/SQL block of code that currently runs in cron that just validates any SQL embedded in our app. (I suppose it is a little "hard-coded" since it does use our naming conventions for packages/functions to parse the PL/SQL calls from the Meta Data but it might still serve as a usefull starting point...) Since our AppEx app(s) sit on top of a database schema that is in fairly constant flux, we need the ability to know when somebody has changed something in the schema that needs to be accounted for in AppEx. The job primarily just parses the AppEx meta data to find PL/SQL function calls that return SQL, executes that PL/SQL to get the generated SQL, then just validates that SQL and reports back any invalid SQL calls. Perhaps we're in some unusual development environment (15-20 people working on a database schema with 700-800 tables/views) but it seems as though it would be fairly easy, for anybody using PL/SQL to generate SQL (which is a GREAT and powerful thing, by the way - thanks to whoever thought that up in AppEx land) to run into this issue.
Jim C.