Marc - That makes perfect sense, thanks. So, if I understand you correctly, the new apex$row_status and apex$row_num in conjunction with editable column names using :foo notation can be used pretty much to do the same thing as a row-level before insert/update/delete trigger i.e. run some code for every changed row (or all rows depending on the selected scope) and the code has full access to the *:new* values of the row. Coming to think of it the trigger can access the pre-change values using the *:old.col_name* notation while APEX cannot but this is a pretty powerful, almost-declarative enhancement to tabular form in APEX, no more messing around with the g_fxx arrays. Great job, kudos to the team, well done.
Thank you for your nice feedback, and yes, that is correct, you have access to these pseudo-variables, and all column values values that were submitted via bind variable syntax. And no need to looping through the apex_applicaiton.g_fxx arrays anymore. I just posted a very simple example in this thread: Re: Updating Tabular Form updates both checked and unchecked rows.
Two small comments, on top of Marc’s example:
If you choose to use this new feature for actual DML actions on the Tabular Form table (as in Marc’s example) you should bear in mind that you can’t use the built-in DML processes, in the same cycle. Your process should be conditioned with a different button than the Submit button, as in Marc’s example, otherwise you’ll get an optimistic locking error message.
And while on the subject of Optimistic Locking, if you are using this technique to update a table, and you are working in a multi-user environment, you should take care of the Lost Update issue yourself.
♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.
♦ Author of Oracle Application Express 3.2 – The Essentials and More