"The selected record has been modified by another user since it was retrieved. Please continue. (SBL-DAT-00523)”
Possible Case 1- The record in the context of current memory on a query output is updated by another memory context of same record.
- A workflow process in Siebel attempted to update a record that another user or task updated since the application initially retrieved the workflow process.
- Try to use the methods RefreshBusComp() method or RefreshRecord() method depending on your requirement.
- Use spooling or logging to check if error is due to modification number or not. You can extract the driving query and check. If that is the problem then you can resolve it by doing refresh records.
Possible Case 2
Symptoms
In a Task Based UI (TBUI) task which associates contact records to a parent record (such as Activities) for some contact records the following error occurs:
Cause
When contact records are imported via EIM, there are sometimes contacts records with some missing foreign key values. This is not an issue in regular UI, as these are updated as soon as the record is accessed in the UI.
In regular UI, a hidden, behind-the-scenes save is performed and these missing values are populated. However in TBUI when these records are accessed in TBUI, the record is saved and the record that TBUI has in temporary storage is out of sync with the record in the Siebel base tables, and this issue occurs. This issue is likely t occur anywhere there is an Auto Primary property set to Default/Select and the field has no value.
One example of this is the S_CONTACT.PR_SYNC_USER_ID column.
In one case where this issue was documented to happen it was found in the log file for the Contact records, if the S_CONTACT.PR_SYNC_USER_ID = NULL, then associating the Contact to the Activity will trigger TBUI to populate S_TU_LOG for unnecessary "Update" operations on S_CONTACT & S_PARTY. This resulted in the error being shown in the task. If S_CONTACT.PR_SYNC_USER_ID = "No Match Row Id" or some other value, then everything worked fine.
Solution
There are three workarounds for this issue:
#1
1) Query/Select Contact BC
2) Select MultiValueLink "PIM Sync Owner"
3) Change the Auto Primary Value to "None"
#2
Pre-Default the value for Primary PIM Sync Owner Id to "No Match Row Id"
#3
Set Business Component User Property “Immediate Commit In Task” = TRUE for the Contact BC.
This will force the Contact BC to be non-transactional in TBUI, and all changes to the Contact BC to made directly to the Siebel tables. This will prevent the error from happening, but entire task will need to be thoroughly tested to ensure that this does not adversely affect where contacts are reference in other parts of the task.
If need be, the Contact BC can be copied and the Business Component User Property “Immediate Commit In Task” = TRUE for the copy of the contact BC. This will allow the one place in the task to use the non-transactional Contact BC and the rest of the task use the regular Contact BC. This too would need thorough testing, as Bookshelf notes any changes to transactional nature of TBUI requires additional testing.
Symptoms
In a Task Based UI (TBUI) task which associates contact records to a parent record (such as Activities) for some contact records the following error occurs:
Cause
When contact records are imported via EIM, there are sometimes contacts records with some missing foreign key values. This is not an issue in regular UI, as these are updated as soon as the record is accessed in the UI.
In regular UI, a hidden, behind-the-scenes save is performed and these missing values are populated. However in TBUI when these records are accessed in TBUI, the record is saved and the record that TBUI has in temporary storage is out of sync with the record in the Siebel base tables, and this issue occurs. This issue is likely t occur anywhere there is an Auto Primary property set to Default/Select and the field has no value.
One example of this is the S_CONTACT.PR_SYNC_USER_ID column.
In one case where this issue was documented to happen it was found in the log file for the Contact records, if the S_CONTACT.PR_SYNC_USER_ID = NULL, then associating the Contact to the Activity will trigger TBUI to populate S_TU_LOG for unnecessary "Update" operations on S_CONTACT & S_PARTY. This resulted in the error being shown in the task. If S_CONTACT.PR_SYNC_USER_ID = "No Match Row Id" or some other value, then everything worked fine.
Solution
There are three workarounds for this issue:
#1
1) Query/Select Contact BC
2) Select MultiValueLink "PIM Sync Owner"
3) Change the Auto Primary Value to "None"
#2
Pre-Default the value for Primary PIM Sync Owner Id to "No Match Row Id"
#3
Set Business Component User Property “Immediate Commit In Task” = TRUE for the Contact BC.
This will force the Contact BC to be non-transactional in TBUI, and all changes to the Contact BC to made directly to the Siebel tables. This will prevent the error from happening, but entire task will need to be thoroughly tested to ensure that this does not adversely affect where contacts are reference in other parts of the task.
If need be, the Contact BC can be copied and the Business Component User Property “Immediate Commit In Task” = TRUE for the copy of the contact BC. This will allow the one place in the task to use the non-transactional Contact BC and the rest of the task use the regular Contact BC. This too would need thorough testing, as Bookshelf notes any changes to transactional nature of TBUI requires additional testing.
Related Posts
No comments :