views:

1307

answers:

2

When I define a report region's SQL as SELECT * FROM some_table, all is fine until new columns are added to some_table -- then it breaks with a "ORAxxx No data found" error. It is easy to remediate, as it's enough to Apply Changes on the region again, even without making any changes. However, it does not make for a robust application.

Is there some combination of parameters that would allow SELECT * that does not break with new columns? It would be enough to apply any default formatting or heading to the new columns.

I'm aware I could construct the column list from data dictionary and then concatenate everything into the SELECT statement to evaluate, but this seems rather inelegant.

+2  A: 

Normally is not recommended to use SELECT * queries because:

  • Returns all the columns, then the optimizer have less play to do.
  • It makes less robust the applications because adding new columns changes the result of the query giving unexpected results. Without SELECT *, I mean giving exactly the columns you need, adding new columns does not matter to the application.

Anyway, remember that creating a SELECT * for a view, oracle create the view replacing the * for all the columns, may be APPEX is making the same thing.

FerranB
The explicit requirement for this report is "just list the whole table", and the table in question is in a state of flux, i.e. being actively developed. From this point of view, robustness means to me: application not breaking AND listing whatever newest column layout the users intended.
ttarchala
Yes, you are right, for development processes may be necessary this way of queries. Of course, everybody runs SELECT * queries for a lot of issues not to end applications.
FerranB
+2  A: 

Currently your region source is (I presume) set to "Use Query-Specific Column Names and Validate Query". This means that a report column is defined explicitly for each column in the query, and the SQL is expected to be static.

If you change the region source to "Use Generic Column Names (parse query at runtime only)", then it will still work after a new column is added, with the column title defaulting to the column name.

There is another property "Maximum number of generic report columns" that defaults to 60 and must be set to a value big enough to accommodate any future columns added to the table.

Tony Andrews