For everyone facing unexpected the JBO-25014 error using (ADF) BC

Question

Hi,
I think I might have a hint for everyone facing JBO-25014 (Another user has changed the row with primary key oracle.jbo.Key) errors during updates.
I noticed that during updates, we got unexpected behavior: we have a table with an update row trigger defined on it, where we set values for some columns. During updates via ADF BC (we work with JDev 10.1.3 SU3 and JHeadstart 10.1.3 build 78 against Oracle 8.1.7.4, 9.2.0.7 and 10.2.0.1) we noticed that the value of one of the fields updated via triggers was emptied, although the update could in no way hit the logic for this field. So I reproduced the behavior in the Application Module Tester and also reproduced it in SQL*Plus using a PL/SQL procedure: the problem occurs because of Oracle's RETURNING statement, which is used in ADF BC for fields that need refresh after insert of update. We seem to hit bug 4515623: "Update...RETURNING with a trigger can produce corrupt column data".
This should be solved in RDBMS 9.2.0.8 (not there yet) and 10.2.0.2 (already released). I still have to test whether 10.2.0.2 does solve our problem, but I thought I would let you know in advance. Maybe someone can test before I can (I have to set up a 10G DB first, since I work with 9.2.0.7),
Toine van Beckhoven

Answer 1

Here is additional info on this behavior. I was able to install a 10G DB (10.2.0.1) where I could reproduce the problem. After that I installed patch 10.2.0.2 and tried out it the bug was solved. However: the bug is solved, but not correctly, a new bug is introduced which is still a major problem when you use ADF BC on top of tables with Before Update triggers (but as you can see below, with update triggers containing conditional logic!). So this is really a database problem, but with impact on applications using the refresh after update property in ADF BC! The new bug is known as bug 5115882.
Here is the script I used to pinpoint the problem (I highlighted the things that really show the problem):
DROP TABLE test_ts;
CREATE TABLE test_ts (test_ts_id INTEGER PRIMARY KEY,
status SMALLINT NOT NULL, someotherfield VARCHAR2(1), edittime DATE);
CREATE OR REPLACE TRIGGER test_ts_time
BEFORE UPDATE
ON test_ts
REFERENCING OLD AS OLD NEW AS NEW
FOR EACH ROW
BEGIN
-- always update edittime
:NEW.edittime := SYSDATE;
-- only update someotherfield conditionally (when status=1)
IF :NEW.status = 1
THEN
:NEW.someotherfield := 'Y';
END IF;
END;
PROMPT Create one row, with status 1 and someotherfield initially 'N'
INSERT INTO test_ts
(test_ts_id, status, someotherfield, edittime
VALUES (1, 1, 'N', SYSDATE
SELECT test_ts_id, status, someotherfield,
TO_CHAR (edittime, 'dd-mm-yyyy hh24:mi:ss') edittime
FROM test_ts;
SET serverout on
PROMPT Update the row, with status 2 --> trigger logic will not fire
DECLARE
l_someotherfield test_ts.someotherfield%TYPE;
l_edittime test_ts.edittime%TYPE;
BEGIN
FOR i IN 1 .. 100000000
LOOP
NULL;
END LOOP;
UPDATE test_ts
SET status = 2
WHERE test_ts_id = 1
RETURNING someotherfield, edittime
INTO l_someotherfield, l_edittime;
DBMS_OUTPUT.put_line
( 'Returned SomeOtherField (should be ''N'' but is empty in 10.2.0.1): '
|| l_someotherfield
DBMS_OUTPUT.put_line
( 'Returned EditTime (should be greater than selected one before): '
|| TO_CHAR (l_edittime, 'dd-mm-yyyy hh24:mi:ss')
DBMS_OUTPUT.put_line ('-');
END;
PROMPT However: someotherfield is really 'N' so why is it returning NULL --> bug
SELECT test_ts_id, status, someotherfield,
TO_CHAR (edittime, 'dd-mm-yyyy hh24:mi:ss') edittime
FROM test_ts;
PROMPT Update the row, with status 1 --> trigger logic will fire
DECLARE
l_someotherfield test_ts.someotherfield%TYPE;
l_edittime test_ts.edittime%TYPE;
BEGIN
FOR i IN 1 .. 100000000
LOOP
NULL;
END LOOP;
UPDATE test_ts
SET status = 1
WHERE test_ts_id = 1
RETURNING someotherfield, edittime
INTO l_someotherfield, l_edittime;
DBMS_OUTPUT.put_line
( 'Returned SomeOtherField (should be ''Y'' and is ''Y'' also in 10.2.0.1): '
|| l_someotherfield
); DBMS_OUTPUT.put_line
( 'Returned EditTime (should be greater than selected one before): '
|| TO_CHAR (l_edittime, 'dd-mm-yyyy hh24:mi:ss')
DBMS_OUTPUT.put_line ('-');
END;
PROMPT And see: someotherfield is indeed 'Y' so expected behavior
SELECT test_ts_id, status, someotherfield,
TO_CHAR (edittime, 'dd-mm-yyyy hh24:mi:ss') edittime
FROM test_ts;
Output on 10.2.0.1:
Table dropped.
Table created.
Trigger created.
Create one row, with status 1 and someotherfield initially 'N'
1 row created.
TEST_TS_ID STATUS S EDITTIME
1 1 N 16-07-2006 15:11:35
1 row selected.
Update the row, with status 2 --> trigger logic will not fire
Returned SomeOtherField (should be 'N' but is empty in 10.2.0.1): --> bug
Returned EditTime (should be greater than selected one before): 16-07-2006 15:11:37
PL/SQL procedure successfully completed.
However: someotherfield is really 'N' so why is it returning NULL --> bug
TEST_TS_ID STATUS S EDITTIME
1 2 N 16-07-2006 15:11:37
1 row selected.
Update the row, with status 1 --> trigger logic will fire
Returned SomeOtherField (should be 'Y' and is 'Y' also in 10.2.0.1): Y
Returned EditTime (should be greater than selected one before): 16-07-2006 15:11:40
PL/SQL procedure successfully completed.
And see: someotherfield is indeed 'Y' so expected behavior
TEST_TS_ID STATUS S EDITTIME
1 1 Y 16-07-2006 15:11:40
1 row selected.
Output on 10.2.0.2:
Table dropped.
Table created.
Trigger created.
Create one row, with status 1 and someotherfield initially 'N'
1 row created.
TEST_TS_ID STATUS S EDITTIME
1 1 N 16-07-2006 23:47:51
1 row selected.
Update the row, with status 2 --> trigger logic will not fire
Returned SomeOtherField (should be 'N' and is indeed 'N' in 10.2.0.2): N --> ALLRIGHT, this correct, but look further...
Returned EditTime (should be greater than selected one before): 16-07-2006 23:47:51
PL/SQL procedure successfully completed.
TEST_TS_ID STATUS S EDITTIME
1 2 N 16-07-2006 23:47:54
1 row selected.
Update the row, with status 1 --> trigger logic will fire
Returned SomeOtherField (should be 'Y' ...but is the old value 'N' in 10.2.0.2): N --> so a new bug has been introduced so a problem still remains!
Returned EditTime (should be greater than selected one before): 16-07-2006 23:47:54
PL/SQL procedure successfully completed.
And see: someotherfield is indeed 'Y' so the Returned value is now not correct, like it was in 10.2.0.1
TEST_TS_ID STATUS S EDITTIME
1 1 Y 16-07-2006 23:47:56
1 row selected.
I am affraid we need to look at workarounds, because we rely heavily on before update triggers in the DB with conditional logic. I do not really want to change my triggers (for example removing conditional logic...). And it seems that waiting for the Oracle RDBMS to really solve this problem is not viable either (I saw notes that it will be solved in 11G, not in 10 or 9!).
Anyone from the ADF development team that recognizes this problem and is able to verify that this really is a RDBMS problem? The testcases above run on every DB version as a regular user (for example SCOTT) with some create privileges),
Toine