SytelineMaster

There is no simple way for reports to be cancelled from the client in Syteline 7 and 8. The Cancel button for Print Previews only kills the client part of a Preview. The background task continues to run on the TaskMan machine (The TaskMan machine is typically the Utility Server where the TaskMan process is running.)

There is only one way to kill an individual report. When TaskMan starts a report or an EXE it fills in the Process ID field on the Background Task History form with the Windows Process ID. Log on to the TaskMan machine with the same account TaskMan runs under (or an Administrative account). Bring up the Windows Task Manager. On the Processes tab, select the PID. The Image Name will be RunReport (RunReport.exe) for all reports. Click the End Process button.

If the report is running a stored procedure, simply killing the RunReport process on the Utility Server will not kill the SQL process running within SQL Server. However, identifying this process is more complex. There are generally two main approaches.

1) The simple approach is to stop and re-start the MSSQLSERVER service under Administrative Tools on the SQL Server Box. Or simply re-boot the SQL Server box. However, these approaches will stop all databases and would disrupt business. So they are only appropriate after normal business hours or on a test system. Additionally, once the databases are running again, you would need to re-boot the Utility Server in order for it to properly re-connnect.

2) The more specific, less disruptive approach is most complex. You would need to go into Enterprise Manager, expand the Management folder, expand Current Activity and select Process Info. You would then sort the processes by database so you can reduce the number of processes to examine. You would then right-click on each process in that group, look at the properties and attempt to identify the stored procedure associated with the cancelled report. Most likely, you would only be able to make an educated guess as to what that stored procedure might be based on parts of its name sounding related to the type of report that was killed or cancelled. Once you have identified the process, you can then right-click on it and select Kill Process.

3) The following recommendations may assist with getting the information required to kill the SQL server process associated with the ‘bad’ report.

Firstly, log into Syteline and open the Background Task History form and review recent tasks that are currently in a Running status. For each running task, review the parameter detail information searching for the report or utility that was submitted with no Starting and/or Ending data parameters. Parameters are not labeled, so you may need to look at the Report screen to see what options are available and compare them to the parameters listed in the Background Task History form.

Once you know the Syteline report which is suspected of consuming SQL server resources, open Query Analyzer on your SQL Server, select the App database from which the report was submitted, and run the following query:

SELECT scn.ContextName, scn.ProcessID, ci.UserName
FROM SessionContextNames scn (readuncommitted)
LEFT OUTER JOIN ConnectionInformation ci (readuncommitted)
ON scn.SessionID = ci.ConnectionID
WHERE ci.ConnectionID IS NOT NULL

The above query will return a list of SQL server processes and the associated Syteline information. The column ContextName should return the Syteline form that initiated the process. Search the list of displayed ContextName records for the report which you identified from the Background Task History form. Identify the specific process associated with the desired form and User, and note that ProcessID.

You can then kill the process by running the following in Query Analyzer:

kill spid

where spid would be substituted with the ProcessID value returned in the query you ran. For example, ‘kill 109’.

Please note that killing the process will rollback the transaction so if it has been running for some time, it may take some time for SQL to rollback the transaction and for SQL server resources to return to normal usage levels.