Are Virtual Columns a good idea in APEX apps?

Question

Hi all,
Searching for a way to get fields auto-populated (a QTY*PRICE for example) I discovered Virtual Columns.
Looks very good, but.
a) You can't create Virtual Columns under APEX.
b) You can't create Virtual Columns under SQL Developer.
You must do it with SQL directly. And if you do it.
a) You can't insert rows under Object Browser (APEX)
b) You can't modify anything in this table under SQL Developer
My surprise, is, thath as far as I see, Virtual columns exists since 2007, but seems APEX nor SQL Developer, with updates released some days, are'nt compatible with this "new" feature.
There are some reason for this? In Oracle World anybody uses computable fields?
Regards.

Answer 1

I would say "no" to using virtual columns in the database when Apex is laid over them as the front-end app. It just doesn't like them.
If your page in question is about page items, I would do the following:
1. Create a pl/sql function or packaged function in the database to do your computation(s).
2. Assuming you're in version 4.x, create a dynamic action that populates that item by calling the PL/SQL above and returning it to the item.
3. Turn on (most likely) the "fire on page load" option for that dynamic action task.
If it's a tabular form (or the detail region of a master-detail form), oh my this part sucks. I could not find any way around this that wasn't ugly (and even so my workaround is a hack that I don't like) mostly because tabular forms have fewer options for HTML items than page HTML items do and I had to define my computed items as database columns just to support the tabular form, but read on...
1. Make your computed item in the table in question as a column.
2. Make it nullable.
3. Place a check constraint that this column that it must always be null (ugly, but works...e.g.: MYCOL IS NULL)
4. Place a comment on the column as to why you did this so that future developers that see your work know that you had a reason, however bizarre that reason may be (e.g.: '** Do not use ** This is for an Apex workaround. Do not store any values in this column; always derive them.')
5. Build your tabular form and make the computed column readOnly via HTML Element Attributes readOnly="true")
6. Same as #1 above, write a PL/SQL function or packaged function.
7. Make an app on-demand process and javascript to run AJAX to get the value for each row and to set the value.
8. Call the JS and AJAX for every row after the region paints (usually in a DA that is after-refresh of the tabular form region and it calls JS to call your AJAX to get the values for the computed field on every row).
9. Call the JS and AJAX for a single row when onChange fires on another item in the row (presumably your computed value is based on one or more other values on the row in question).
10. Before submit of your tabular form, clear all values in this computed field on all rows using Javascript.
Why did I do it all that way? Because that was the only way I could find to effectively NOT store a computed value in the DB but also that Apex would generate for me the HTML IDs (e.g.: f06_0001, f06_0002, etc.) for the computed fields in the tabular form (without having to do a fully manual tabular form) so that I could manipulate the fields real-time w/o the user submitting the page, all while not giving me errors about checksums or virtual columns.