Lock records in non-db blocks....

Question

Hi,
I make a test:
Run the same form twice - as two users would do - and try to update the same record almost simultaneously .. then a row lock is established - as expected.
I try another test:
Run the same form twice - as two users would do - and try to update the same record almost simultaneously , but the block is non db (control block). The update is done via a button.
I have written the following simple code:
DECLARE
     EMPNO_VAR EMP.EMPNO%TYPE;
BEGIN
  SELECT EMPNO INTO EMPNO_VAR FROM EMP
    WHERE EMPNO=:EMP.EMPNO FOR UPDATE;
  UPDATE EMP SET ENAME=:EMP.ENAME , JOB=:EMP.JOB ,
               HIREDATE=:EMP.HIREDATE , SAL=:EMP.SAL
               WHERE EMPNO=EMPNO_VAR;
  COMMIT;
END;The result of the following is what Tom Kyte names "lost updates".... The update of the second user overwrite the update done by the first user ....
No lock row is established....
I have also tried:
DECLARE
     EMPNO_VAR EMP.EMPNO%TYPE;
BEGIN
  LOCK_RECORD; 
  UPDATE EMP SET ENAME=:EMP.ENAME , JOB=:EMP.JOB ,
               HIREDATE=:EMP.HIREDATE , SAL=:EMP.SAL
               WHERE EMPNO=EMPNO_VAR;
  COMMIT;
END;   But , no update is done ....
How can i lock the record in a block which is non-db (control block)...???
Note: I use Oracle db10g v.2 and DevSuite Form 10g
Thanks...
Sim

Answer 1

Sim, you are missing a whole second part of this scenario. You initially retrieve the row's data in the WNFI trigger.
If you want to prevent the "Lost Updates" problem, you need to do what Forms default (automatic) processing does before it allows the second user to update a field. When the user makes the very first keystroke to make the first change in a base-table row, Forms does a select * for update nowait. THEN, it compares all the data fetched in this SECOND fetch with the database values stored for the row in the FIRST fetch. If they do not compare exactly, then some other user has updated the row and committed. In that case, Forms displays the message:
FRM-40654: Record has been updated by another user. Re-query to see change.
So, you need to do the same thing in your form, but you will need to do it manually.
When you initially fetch the data in the WNFI trigger, you need to store a copy of the values retrieved someplace where they will not be changed by the user. Then when your button is pressed to update the record, you need to select all the columns your form updates in the select... for update nowait.
At this point, you check for a locked row by checking for ORA-00054. If not locked, you then need to compare all the stored values against the new values fetched. If they compare equal (and here, be sure to treat null = null as true), you can continue. If they do not compare equal, then you need to prevent the update, and issue a message similar to the FRM-40654.
If the row is not locked and they compare equal, then you can go ahead and update the row. And be sure to update the values stored for a possible next comparison.
Whether or not you commit after the update is up to you. If you commit, it frees up the lock so another user can make the change. If this is the only change the form can make, then a commit is ok. But if this is only part of the changes a user can make, then I would not commit, and require the user to click a save button at some point, which would then commit all the changes.
Good luck!