Friday, 20 November 2015

ADF : Another User Have changed the Row with Primary Key in ADF | oracle.jbo.RowInconsistentException: JBO-25014

This post is relating to the error that often comes on ADF Applications.

Error : oracle.jbo.RowInconsistentException: JBO-25014: Another user has changed the row with primary key

Main Cause
This comes up when user commits the data on ADF page, the framework checks whether if the row which is being modified and being committed by the current user is still in the same state as it was when the framework fetched the row from the database.

Scenario :
  1. Suppose a user A wants to modify the Salary of an Employee with Employee_id 10.
  2. He picks the row and started editing the record and sets the Salary to 3500.
  3. Meanwhile a new user B who also wanted to update the Salary of Employee_id 10 picks the record and edits the record and sets the Salary to 3000, and commits the record.
  4. Now if the user A commits the record then this error will appear.
    • This will appear as when the user A started editing the record, at that time framework made a copy of same record and kept with it.
    •  When the user A completed its entry and try to commit the record, then the framework compares the record saved with it and the same record currently in the database.
    • This is to ensure that while the user A was editing the data then the same record was not modified by any other user. This done to maintain the consistency of the database.
    • As if the A is allowed to commit the data then the changes made by B will be lost.
    • This is the scenario in case of Optimistic Locking Mechanism. If you want to know more about Locking mechanism

Normally this is case. But in ADF Applications this comes up even if the Another User is not modifying the record.
Here are some of the causes :
  1. Formatting in case of Date Columns.
    • Problem : Suppose the Date saved as timestamp in database as '12-11-2015 11:10:55.001' and in the ADF Application it is '12-11-2015 11:10:55'. Ideally they are same but for the framework this is a mismatch.
    • Solution :  The trick to avoid this error is to send the data in the database after the formatting i.e.  '12-11-2015 11:10:55' so that on comparison it compares '12-11-2015 11:10:55.000'  and '12-11-2015 11:10:55'
  2. Formatting in case of Number Columns.
  3. PostChanges() being called in the application.
    1. Problem : Data is posted to the database in case of PostChanges(). And if after that the data is modified then again this comes as there is difference between database and framework. Suppose the value of a column is 'A' before postChanges and afterwards it is changed to 'B'. Then on commit this comes up, not always but often in case of PostChanges.
    1. Solution :  This is no particular sure solution to this, but we have certain options
      1. Executing the VO before commit.
      2. We can use Refresh on Insert, Refresh on Modifiy attributes of Entity. Set it to true to avoid this error.

Now as we have done the homework :) regarding this, now It’s a task to identify that on which attribute this error is coming.  Here are the steps.
  1. Start the server.
  2. Go To we logic server console | Actions-> Configure Oracle Diagnostic Logging

  1. Now go set the log to finest for oracle.jbo to finest

  2. Now go to preference in Jdeveloper and increase the log lines to 30000 as too many log rows will be generated.
  3. Now clear the log before the event on which this error occurs then  perform the event.
  4. Then in the log search for text 'Entity Compare failed' and it will show you the attribute name for which this error is appearing and Value.

No comments:

Post a Comment