Error "Unable to modify incident. This incident is being modified by another process." occurs while viewing or trying to edit a Helpdesk incident

Article:TECH157638  |  Created: 2011-04-07  |  Updated: 2012-01-06  |  Article URL http://www.symantec.com/docs/TECH157638
Article Type
Technical Solution

Issue



A Helpdesk incident is unable to be edited. When viewed, the top of the incident shows the message "This incident is being modified by another process."


Error



If trying to edit the incident: Error editing incident.

This will appear whether viewing or editing the incident: This incident is being modified by another process. Click here to update the view. Refresh.


Cause



The incident is locked. This can be caused by a variety of issues:
 

  • A processing job has targeted the incident for editing, which is waiting to be processed. This should eventually finish, enabling the incident to be later edited. For example, bulk edit jobs, automation rules, incident rules and other business rules that modify the incident's values. This is therefore a normal and expected message.
  • A processing job has targeted the incident for editing but never completed. The incident will need to be manually unlocked. Before doing this, ensure sufficient time has been granted in the case that the job is still processing and hasn't had time yet to modify the incident in question.
  • A processing job has invalid criteria, resulting in the locking of an incident. This too will need to be manually unlocked. The root cause will need to be researched, as there is no simple method of determining at a glance what locked the specific incident other than to review what was running at the time in the Helpdesk database.
  • The Helpdesk server experiences heavy use and/or has large comments in incidents, resulting in at least a partially unstable database environment.

Solution



Follow the below instructions to resolve locked incidents. Note: The root cause may still need to be found and resolved (listed below in the Root cause investigation and additional troubleshooting section), however, otherwise additional incidents may periodically also become locked.
 

  • If incidents are determined to be permanently locked, locate these in SQL and manually unlock them:

    1. In Microsoft SQL Server Management Studio, run the following query:

    USE Altiris_Incidents
    SELECT Number AS "Incident No.', Title, UpdateLock AS 'Locked' -- If an incident is locked, it will have the UpdateLock value of 'c' or otherwise not an empty value. If not, it will be empty.
    FROM workitem
    WHERE UpdateLock <> ''
    -- All locked incidents are displayed.

    2. If it is believed that these are all permanently locked, unlock these by running the next query:

    UPDATE workitem
    SET UpdateLock = ''
    WHERE UpdateLock <> '' -- or WHERE number = <affected incident number>
     
  • If incidents are determined to not be permanently locked, it is recommended to allow time for normal operations to occur for the edit process of the incident. If this cannot be waited for, change how incidents editing is performed by doing the following:

    1. In the Altiris Console, click on the Configuration tab. (If using Console 6.5, click on the View menu > Configuration.)
    2. Click on to expand Server Settings > Notification Server Settings.
    3. Click on Incident Settings.
    4. Click to uncheck "Process deletions and multiple incident edits".
    5. If "Process deletions and multiple incident edits -- Incident processing interval" is lower than 60, change this back to 60.
    6. Click on the Apply button.
     

After performing either solution, open a new Helpdesk Console (or closing the one that was open that was previously used to view the locked incident) and view the incident. The message should now be removed.

Alternative solution

While the above SQL queries work fine for finding and unlocking locked Helpdesk incidents, it's not always the most convenient way to do this as the user would have to have access to SQL. As Altiris Reports access SQL, these same queries can be easily adapted into custom reports to do the same thing. This enables the user to easily find and correct the issue in the Altiris Console under Reports. (Also, other aspects of Helpdesk may be able to be used for this, such as tasks. Anywhere SQL can be directly accessed in Altiris and Helpdesk at can be used for this.)

Included as attachments to this article are two sample custom reports. Please note that these are provided AS IS with no guarantee of functionality. These should be tested on a development database before running them against a production database to ensure they meet the user's needs.

Description:
 

  • CUSTOM REPORT Display locked Helpdesk incidents.xml. This performs the first query to locate any locked incidents. As noted, these are not necessarily permanently locked. The modified date/time should be checked against the current date/time to help verify if the incident has really been permanently locked, assuming a worker is not currently editing the incident.
  • CUSTOM REPORT Unlock permanently locked Helpdesk incident.xml. This prompts the user for an incident number that is permanently locked and then unlocks it, using the second query.
     

To use these, open an Altiris Console and then go to Reports. Right click on the Reports folder (or otherwise under Reports, where you wish to save the report to), then choose Import and select the reports to bring in. Then, run the reports.

Root cause investigation and additional troubleshooting
 

  • Incidents can be manually unlocked by modifying their database record. Before doing this, ensure that a normal processing job is not still working on modifying the incident. Current processing jobs can be found by running the following SQL query against the Helpdesk database, which by default is Altiris_Incidents:

    USE Altiris_Incidents
    SELECT *
    FROM jobqueue
    -- This will list any pending jobs that could be waiting to modify the incident in question. Allow these to complete before manually unlocking the incident.
     
  • Check the following areas in a Helpdesk console:

    * Edit Multiple Incidents. Click on the Incidents menu > Edit Multiple Incidents.
    * Delete Incidents. Click on the Incidents menu > Delete Incidents.
    * Automation, Incident and Routing Rules. Click on the Admin menu > <rule type> Rules > List <rule type> Rules.
     
    Any non-standard or modified business rule can be potentially causing this issue.
     
  • Further analysis may be obtained by running the Helpdesk console in debug mode and then reproducing the issue (going to a locked incident). Debug mode can be ran by going to the following modified Helpdesk console URL:

    http://<server name>/AeXHD/worker?awdebug=logbrowser

    This will create a red debug text output at the very bottom of the Helpdesk console window.
     
  • Reviewing the Altiris logs may also help. These are located in the <Altiris_installation_drive>:\Program Files\Altiris\Notification Server\Logs folder and can be accessed using the Altiris Log Viewer in the Altiris program folder in Windows. For example, validation rules (and other business rules that can modify an incident) can cause this. The following related article describes this in more detail: 

    When a job to Edit Multiple Incidents is submitted, it does not complete and sometimes leaves a few target incidents locked
    http://www.symantec.com/business/support/index?page=content&id=TECH26111
     
  • A SQL trace may also prove useful. This can be performed by the Helpdesk database's DBA.
  • The SQL Server used by Helpdesk is very busy. This can be found by looking in the Altiris server logs for "deadlock" and "timeout" errors. The environment can affect this. Ensure that SQL is not under a burden and has sufficient resources.  For example, does this randomly happen during the production day but doesn't when the server is less busy or off-production? If so, then this is very likely a resource issue for the SQL Server administrator to assist with.  In addition to this, large comments may also result in this indirectly, as they will often result in instability for the Helpdesk database. This is discussed in the following article:

    Incidents with large comments cause slow performance, timeouts or out of memory errors in Helpdesk
    http://www.symantec.com/business/support/index?page=content&id=TECH145515
     

Related Article

Error, "Cannot insert the value NULL into column 'tag_collection_id', table 'Altiris_Incidents.dbo.tag'"
http://www.symantec.com/business/support/index?page=content&id=TECH12142




Article URL http://www.symantec.com/docs/TECH157638


Terms of use for this information are found in Legal Notices