Troubleshooting Workflow Process and Scripting Issues

Article
06/14/2014

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

This section addresses issues relating to the requirements for the Workflow Designer for SQL Server workflow engine and the components of the workflow process.

Workflow Process Requirements and Limitations

When implementing a workflow process in your workflow application, it is important to consider the following issues:

Multiple developer scenarios are not supported in Workflow Designer for SQL Server. Two developers cannot make schema changes to a workflow application simultaneously.
Only one workflow process can be defined per user table.
There is no debugging support for the workflow script editor. Use the Logger object to debug your script.
Make sure your script has error handling for cases where user directory information is not available. For example, make sure your project still works correctly even if a user's e-mail address or manager is blank or Null.
Verify that the names used in the script functions and procedures match.

Reapplying Workflow to Items Whose State Was Deleted

The workflow process controls items that are in valid states that are part of the workflow. If a state is deleted from the workflow process, then that state is no longer valid, and items in that state are not subject to the rules of the workflow.

The purpose of the workflow process is to control changes in state. Therefore, updates from a lost state to a valid state are prevented.

To reapply workflow to items whose state was deleted

Open your workflow project in the Workflow Designer.
Expand the Workflow Processes folder in the Solution Explorer, and select the workflow process on which you want to work.
Disable workflow enforcement by setting the EnableWorkflow property in the Properties window to False.
Open the workflow-enabled table in SQL Server Enterprise Manager.
Update the modStateID value of the affected records to a valid state ID.
Return to the Workflow Designer, and set the EnableWorkflow property of the workflow process to True.

Recovering Workflow After a Table Name Change

If the name of a table that has a workflow process associated with it is changed, the workflow process can no longer track the items in the table. You can modify the modSystem database tables to correct this problem.

To recover workflow after a table name has changed

In the modSystem database, open the modObjects table for the workflow application, and replace the old table name with the new one in the Name column.
In the SQL Server Query Analyzer, run the modProcessTable stored procedure against that database.

Trigger Execution Order

In Microsoft® SQL Server™, the order of trigger execution is not guaranteed. If you define one or more triggers for a workflow-enabled table, those triggers might interact unpredictably with the workflow triggers created on that table.

Workflow Script Debugging on the Server

Members of modAppOwners Microsoft® Windows® group have the permissions required to develop workflow applications. However, if you are attempting to debug workflow-scripting code on the production server, you must have access to the modWFE.log, which is created in the system32 directory of the server when the first log message is written. Typically, only users with administrator privileges have access to such files on a server.

If you must debug against a production server, contact your server administrator to grant you access to the file.

Share via