Friday, February 7, 2014

Explaining Change Indicator Property for ADF BC Attribute

There is one not very visible, but quite powerful property available for ADF BC Entity Object attribute. This property is called - Changed Indicator. By default, during commit operation, ADF scans each changed attribute from the current row and compares value in the DB. If it locates changed values in DB, reports error about another user changes in the same row. While this is expected functionality, there are use case when we want to allow commit, even data was changed already by someone else. For example, in more complex systems, data is updated by PL/SQL procedures, we don't want to inform user with error about this. There is a way to override lock method in EO implementation class, catch lock error and raise lock again. This works, but there is different way - to use Change Indicator. This property defines specific attribute to be responsible for row data changes tracking, instead of checking every attribute. Only if Change Indicator attribute value will be changed in DB, then current row changes will be prevented and user will be informed about someone else changes in the same row.

My previous post - Different Approach for DB Constraint Error Handling in ADF, about handling DB constraint errors is using Change Indicator defined for Primary Key. In this way, I'm completely ignoring changes by other users and allowing to commit data no matter if it was changed by someone else.

Here you can download sample application with Change Indicator demo - Change Indicator can be set on EO attribute, I'm using Department Id in this example. This would mean, all changes are allowed without informing a user about new changes in DB, except when Department Id is changed:

I'm running sample application with two different sessions. Changing Salary value in both sessions, for the same row. Salary is changed in the first session, but not yet committed:

The same row Salary is changed from the second session and committed with Save button:

Committing from the first session, data in the same row, doesn't bring error about data changed by another user. As expected, since Change Indicator value was not changed - ADF doesn't know about changes in the DB:

If I would invoke rollback in the second session now, by pressing Cancel button - I can see that the last updated Salary attribute value is displayed:

We can simulate data change in the DB and trigger update in Change Indicator. Let's update Change Indicator column value and commit this change:

Go back to the ADF UI, change data in the same row and try to save it:

Change Indicator value was changed, we are going to get error about another user changes in the same row - as expected this time. Notice that Change Indicator value is updated, Department Id is set to 30:

As it works by default in this case, press Save button second time, data will be saved for the new Department Id:


Anonymous said...


This is important to avoid possible data corruption.

see als "ADF Code Guidelines - include new change indicator mandatory recommendation?"

"When an entity object is updated concurrently by more than one user and one of those users loses affinity with their application module during the update, it is possible to experience data corruption if a change indicator has not been defined for the entity object. ..... To avoid this type of scenario, define a change indicator attribute for all entity objects"

Jan Vervecken

Andrej Baranovskij said...


Ok, here I'm using change indicator for different purpose.

Your case sounds like ADF bug. Keep in mind, this is not always possible to find one single change indicator in EO.

I think better is to override EO lock method and in case of exception, catch it and try to lock again.


Anonymous said...

super andre

Ubai said...

Honestly unbelievable , we have a use case that Users can make update on same Row on Different Columns without bothering each other, and really it was not an easy use case with default Change indicator on Row Level .
but with your post life became so easy, the user can be notified about others' change during commit and they still have the ability to commit their work while they are checking others change.

Thank you very much for such straight forward solution for a difficult use-case .