The RAD performs unnecessary updates to probsummary records.

  • KM494309
  • 04-Sep-2008
  • 19-Dec-2016


In ServiceManager 7.0.X, the RAD that is automatically schedule after updating any Incident (probsummary) record. The result is the History tab of nearly every Incident Management record shows the as problem. SCR42003 has been opened to address this issue.


The main error/issue is that all probsummary tickets will show the as 'problem'

RAD: ServiceManager 7
Binaries: SM7.0.1
Server OS: Windows Server 2003 Enterprise Edition
The RAD that is automatically scheduled after updating any Incident (probsummary) record.   The result is that the History tab of nearly every Incident Management record shows the as problem. While it is reasonable to have problem update as necessary for Alert Stages.

Steps to Replicate:

1. Startup an SM 7.0.x system with all of the background processes running (lock on display disabled).
2. Create a new Incident Management record; be sure to populate with a CI Item.
3. Perform an update on the IM record opened in step 2 by clicking Save and remaining on the record.
4. Sit on the record for a few minutes - the problem process will run the RAD via schedule record in the background.
5. After a few minutes, attempt to type in the record and note that the system prompts for it to be refreshed as it as been modified since last read.
6. Check the History tab and note that the problem user/process was the last process to update the record - in only a few minutes we have already lost the value!
7. Perform another update on the record, wait a few minutes for problem to re-run the RAD.
8. Confirm that ANOTHER update was made by problem even though no data is actually changing within the array - why perform an unnecessary update and causing database activity and loss of useful historical information?


The RAD code does not successfully perform a check to see if the array actually needs to be updated, it updates the probsummary record regardless of whether data is changing or not. This can be seen by breakpointing within the workflow while executing through the test.schedule RAD App:
Breakpoint reached for Panel: verify.valid
|5| verify.valid
|5| RAD:
d in $L.appl=$
d in $L.appl
d $


QCCR1E31306 Changes/incidents are updated by the '' application even when there are no new changes to save

Technical solution:
1) Process ""
calls RAD ""
Condition should contain
... and not same( in $, in $L.file)

2) Process ""
initial expression should contain this:

$L.orgCis={};if (not null( in $ then (1 in $L.orgCis in $;if (lng(denull(assets in $>0) then ($L.orgCis=$L.orgCis +denull(assets in $

RAD call "" should contain
pre expression
$L.saveCis={};if (not null( in $L.file)) then (1 in $ in $L.file);if (lng(denull(assets in $L.file))>0) then ($L.saveCis=$L.saveCis+denull(assets in $L.file))

and condition
... and  $L.saveCis ~=$L.orgCis