How to stop insert of new row in tabular form if it's also being deleted

Question

Suppose you have a tabular form, and one of the fields is a not-null column. A user checks a button to "add additional row", which adds a new row to the form, defaulting that not-null column to null. Assume it's a name or something, so there is no reasonable non-null default value that can be entered here to keep it from being null.
Now suppose the user makes a series of changes on the page, but then decides they don't want that row they just added, so they mark it for deletion, then click on "Delete Checked Rows". The not-null column was left blank.
The page is constructed in such a way that the ApplyMRD process runs first, then the ApplyMRU process. (I do this so that the user doesn't lose all their updates if they want to delete a row. I've had a few people complain when they tried to combine both operations, and unexpectedly lost their updates when they hit delete instead of submit.)
What happens? The page errors out because the ApplyMRU process is trying to insert a row with a null value in a not-null column. The ApplyMRD process ran fine, but because the row marked for deletion didn't exist in the database to begin with, it effectively did nothing. But ApplyMRU still tries to add the row, even though it was marked for deletion.
Is there any way to prevent this scenario from happening, without requiring the user to Cancel instead of deleting the blank row, which would cause all other changes on the page to be lost? I'd also like to avoid losing the ApplyMRU process when the user clicks "Delete", since it's more effective to combine operations and this will address the UI complaints I'd received otherwise.
(This is on ApEx 4.0, if it matters.)
Thanks,
Keith

Answer 1

Thinking about this some more, doing the delete and update together may not be an easy thing to accomplish after all.
Consider the above scenario, but the user puts a dummy value like "ignore-me" into the not-null text field, so the error doesn't come up with ApplyMRU is fired. But if ApplyMRD runs before ApplyMRU, it still doesn't do anything because there is no row in the database with the value "ignore-me". Then ApplyMRU runs and it adds that row, even though it was marked for deletion.
So you probably need to always run ApplyMRU before ApplyMRD. But then you wind up inserting a row before you delete it, and that may have unintended side effects, if the user really never wanted to add it in the first place.
Right now, the only workaround I can think of is to:
1) put ApplyMRU before ApplyMRD
2) add a pre-commit validation that checks to see if a row is blank AND checked, and if so, put a dummy value into the not-null field
3) let that row get added and then deleted, and make sure there are no side effects from this (for example, there is an audit table that tracks updates to the base table -- I can add a trigger that does nothing if presented with this dummy value)
Hopefully, though, there is an easier and more "built-in" way to achieve what I'm aiming for.