Siebel is an application accessed by users through browser. There is no external controls to prevent different users from working on the same record. The record may also be updated in the local database on Siebel Remote Client/Mobile devices. Even with all this going on it is quite simple to determine which transaction will have the final say.

Multiple updates on server #

This is the most common scenario where more than one user starts updating the same record in distinct sessions.

Siebel controls the updates through a Column called “MODIFICATION_NUM”. This column is present in all Siebel tables, and will have integer values >=1.

Each time users queries on a particular record, Siebel retrieves the modification number as well. The application will then pass this modification number through the update SQL. The final update is performed on the database only if the modification numbers in the database and the value provided in the SQL differ by 1.

If there is an update by another user or a backend logic on the same record, the modification number in the database would have changed. The difference will lead Siebel to recognise that the state of the current update is stale, and no updates are performed in the database. The user will get the following error -

The selected record has been modified by another user since it was retrieved. (SBL-DAT-00523)

The user would have to redo the changes and retry.

Application will produce this error regardless of the user trying to update the record - it is the same treatment for backend scripts/workflows, administrators, and normal users. This error can be reproduced on remote clients as well.

Handle updates on server/client #

Siebel remote client uses a local database for all transactions off-line. These changes and then try to synchronise with the server. This may lead to multiple conflicts -

• More than one remote user may have updated the same record
• Same record gets updated in server as well as in client
• Deletes and insert conflicts may also occur. For example User1 deletes a record, while User2 has updated the same record

You can set preferences on how to treat this situation for your own implementation. Following typical actions occur in case of conflicts -

• Updates in either client or the server are retained based on whether “client wins” or “server wins”.
• In case of a duplicate, Siebel creates the new duplicate record and sets an integer value in “CONFLICT_ID” column. The application continues to show records with CONFLICT_ID=0. Impacted users are shown the conflicts, and they can take action to correct data, or use the existing data in order to avoid duplicate.
• Deletes always win. Siebel remote/server will delete the record irrespective of any updates carried out in other clients/by other users.

It is a best practice to show conflicts to the remote users, and train them to resolve the conflicts after synchronisation.