How come the item value does not come thru via PL/SQL anonymous block?

Question

Hi,
It's a Form with 3 tables -
1) ClinicianProfileTb (with about 40 columns, insert/update via DML),
2) PeopleTb (with about 7 columns, insert/update via PL/SQL anonymous block) and
3) ClinicianPracticeTb (with about 10 columns, insert/update via PL/SQL anonymous block) for after-submit-processes.
So I have several After-Submit-Processes. For some reason, it appears that PeopleId which is supposed to come thru via the 2nd After-Submit-Process (ie: Insert/Update PeopleTb) does not do the way it's supposed to. And when I press "Create" button at the bottom, I got the following error msg:
ORA-01400: cannot insert NULL into ("TEST_0712"."CLINICIANPRACTICETB"."PEOPLEID")
I tried the "debug" mode (via edit page link), but to no avail. (I'm newbie, trying to learn and deliver at the same time :)).
I uploaded the app to apex.oracle.com, if someone could kindly take a look and let me know what goes wrong, it'd be greatly appreciated.
workspace: test_0712
app: 43408 - TEST
user: demo
pswd: demoPswd
Page#21 -> look at the After-Submit-Processes -> in "Insert/Update PeopleTb" it appears that PeopeId does not come thru; thus it cannot be updated to ClinicianProfileTb.PeopleId (allows null) -> and thus cannot be inserted into ClincianPracticeTb.PeopleId (which does NOT allow null). Basically my logic is that in order to create ANY row in ClinicianPracticeTb, BOTH PracticeId AND PeopleId must be present.
Acutally I should have used the PeopeTb as DML (as the driving table) to enforce that PeopleId must be present in order to insert ClinicianProfileTb and ClinicianPracticeTb, but it'd be lots of codes to write to insert/update in ClinicianProfileTb (40 columns).
In addition, does ApEx consider EVERY SINGLE after-submit-process are in ONE transaction for commit/rollback? It appears that it treats all PL/SQL anonymous blocks are in ONE transaction, while Automatic Row Processing (DML) is commited/rolled back on its own?
Thanks much,
Helen

Answer 1

All blocks that do not commit in one of the ways I detailed (and which do not explicitly commit using a commit statement) are part of the transaction started with > the first DML statement issued in any of the page processes and continuing until a commit is issued.Say, there are the following processes in the After-Submit-Processes:
1. Process1 -> Automatic Row Processing (DML)
2. Process2 -> PL/SQL anonymous block
3. Process3 -> PL/SQL anonymous block
Based on what you describe, in the event that if there is no explicit "commit" issued in any of these processes, then an implicit "commit" will be issued at the end of Process3?
Thanks, Scott.
Doreen