A lot of times you must have encountered the error mentioned below
SBL-DAT-00523 : The selected record has been modified by another user since it was retrieved.
This error message signifies that somebody else was quicker than you and has already modified the record, so you need to perform the update again. This is common occurring scenario where lot of updates are happening either thorough Policy Workflows or Asynchronous requests in addition to synchronous updates either on UI or scripting. This article attempts to explain How Siebel Applications handle the concurrent attempts to update a record?.
When a user accesses a record via business component either from UI or scripting, both Row Id and Modification Number field values are retrieved by Siebel through SQL for example:
SELECT ROW_ID,MODIFICATION_NUM, OTHER_COLUMNS,…. FROM SIEBEL.S_OPTY
Now let’s assume that Row Id retrieved from above SQL is 1-12345 and Modification Number is 1
When user modifies something on the UI or scripting an Update statement is triggered and the where clause of the UPDATE statement has both ROW_ID and MODIFICATION_NUM column in it. Also in update statement Modification number is incremented by one for example:
UPDATE SIEBEL.S_OPTY SET MODIFICATION_NUM = 1+1,OTHER_COLUMNS = ‘ABC’,…. WHERE ROW_ID = ‘1-2345’ and MODIFICATION_NUM = 1;
If another user access the same record between query and update they would get the same modification number ‘1’ along with ROW_ID ‘1-12345’
Now lets assume that update by other user happened before our update which means that now the modification number on DB has already been update to ‘2’. Therefore where clause would fail as there wouldn’t be any record with MODIFICATION_NUM = 1 and we would get SBL-DAT-00523 error.
When you re-query the record next time you would get modification number as 2 and your update this time will succeed (provided your are fast enough 🙂 )