WITH clause unexpectedly causes ORA-00942 in Reports Builder

Question

I'm posting this in the hope that:
a) My workaround might help someone if they ever run into the same problem, and/or,
b) Someone might have a better workaround.
The problem is that I get unexpected ORA-00942 (table or view does not exist) errors when I try to set the SQL Query Statement property of a Query object in Reports Builder to certain SELECT statements that contain a WITH clause (aka subquery factoring clause).
For example, the following SELECT statement executes as expected in SQL*Plus...
SQL> WITH
  2      SUB_QUERY AS
  3      (
  4          SELECT
  5              1 AS X
  6          FROM
  7              DUAL
  8      )
  9  SELECT
10      INLINE_VIEW.X
11  FROM   
12      (
13          SELECT
14              NESTED_INLINE_VIEW.X
15          FROM
16              (
17                  SELECT
18                      SUB_QUERY.X
19                  FROM
20                      SUB_QUERY
21              ) NESTED_INLINE_VIEW
22      ) INLINE_VIEW;
         X
         1...but when I try to use it as the SQL Query Statement for a Query object in Reports Builder, I get the following error:
ORA-00942: table or view does not exist
==>SUB_QUERY
My Reports Builder version is 10.1.2.0.2 version and my database version is 10.2.0.3.0.
The "real" query I have been trying to use is much more complex than this -- this is just the simplest statement I have been able to come up with that causes the problem. In fact, I have some queries that have a similar structure (a WITH clause subquery referenced inside a nested inline view, along with some other things), but strangely do not cause the problem.
I spent some time researching the problem on Google and Metalink but did not come up with any satisfactory answers. The problem sounds similar to bug 3896963, but bug 3896963 involved UNION ALL, and is supposedly fixed in my version(s).
I tried various ways of restructuring my "real" query, but with no success -- it's going to be hard to get rid of the WITH clauses. As a "wild guess", I tried various hints (MATERIALIZE, NO_PUSH_PRED, NO_MERGE), again with no success.
I ended up working around the problem by creating a database package with a function that returns a REF CURSOR based on the query, and then used that in a REF CURSOR query in Reports Builder. It might not be a very elegant workaround, but it works. I just wish I had "given up" and tried it sooner -- I might have saved myself some grief.

Answer 1

Well, for what it's worth, I didn't end up using a REF CURSOR query after all because...
If I ran a REP file based on a REF CURSOR query against a different database, or if I ran the REP file after the database package had been dropped and re-created, it failed with the following error:
REP-8: Run time error in the PL/SQL development environment (DE).
PDE-PSD001 Could not resolve reference to <Unknown Program Unit> while loading <Unknown> <Unknown>.
REP-0008: Unexpected memory error while initializing preferences.
It seems that Reports "binds" the REP file to the timestamp of the database package that defines the REF CURSOR type in order to validate the package at run time. If the timestamp is different, running the REP file will fail with this error. This is apparently bug 1275333 and is described in Metalink Note 272936.1.
The bug reference and Metalink Note offerred the following workarounds:
1. Export the database schema that contains the package from one database and import it into the other.
In some versions, import and export preserve the timestamp, so this would avoid the problem. I didn't try this because it would not be a practical workaround in my situation (upgrade vs. new install).
2. Recompile the package and manually set the timestamp using the seemingly undocumented ALTER PACKAGE...COMPILE BODY REUSE SETTINGS TIMESTAMP... syntax.
I didn't try this because I didn't like the idea of having to: a) rely on an undocumented feature, and, b) manually keep track and maintain the timestamps of all the affected packages across several databases (e.g., development, test, and production).
3. Put the package into a Reports library or into the report itself.
This didn't work for me because Reports does not understand WITH clauses in PL/SQL. For example, with the example query in my previous post, I get an error like this:
Error 103 at line {line defining name of factored subquery}, column {first column in line defining name of factored subquery}
Encountered the symbol "SUB_QUERY" when expecting one of the following:
&lt;a SQL statement&gt;
4. Use an RDF file instead of a REP file.
I didn't use this workaround because I wanted to protect the design of the report by using a REP file instead of an RDF file.
So instead, I:
1. Created a database package containing a pipelined function that returned the results of the WITH clause query that Reports did not "understand".
2. Used an SQL query in my report of the form
SELECT * FROM TABLE(MY_PACKAGE.MY_PIPELINED_FUNCTION(arg1, arg2, ...))
I can drop and re-create the package and run the REP file against another database both without leading to the REP-8 error.