BICC extract fails with ORA-00918 “column ambiguously defined”? Curate the column list
Some wide Oracle Fusion PVOs can't be extracted with every column selected. Here's why, and the fix that makes them run.
You create a BICC job for a wide PVO, select all columns, fire it — and the run fails with 0 rows. The status file
shows nQSError 17001 wrapping ORA-00918: column ambiguously defined.
What's happening
Every PVO is backed by generated SQL that joins many Fusion tables. On some very wide PVOs, two join-sourced columns end up with the same unqualified name in that generated SQL. Oracle rejects the whole statement. It isn't your filter or your watermark — the plain, unfiltered extract fails the same way.
We've seen this on wide planning PVOs, for example the project plan version forecast/budget PVOs with roughly 280–290 columns.
The fix: select fewer columns
Trim the job's column list to what you actually need. Dropping the colliding column makes the generated SQL valid again. A good minimal set:
- the primary key column(s),
- the
…LastUpdateDatewatermark column, - WHO columns (created/updated by and date),
- the business columns your reports use.
| PVO | Columns | Result |
|---|---|---|
| Project plan version (forecast) | 282 → 11 | FAILURE → SUCCESS, 2,453 rows |
| Project plan version (budget) | 293 → 13 | FAILURE → SUCCESS |
Bonus: curation is also faster
Narrower PVOs extract faster and produce smaller files, which is why production pipelines rarely select every column of every PVO. Use a data dictionary to pick columns deliberately instead of trial and error.
See it on your own Fusion data
The free SQL editor queries tables and PVOs, and the catalog shows every PVO's columns and underlying SQL.
Request free access