Troubleshooting: Workflow Process and Scripting Issues

See Also

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

For information about specific error messages, see Error Messages.

Workflow process requirements and limitations

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

• Multiple developer scenarios are not supported in Access Workflow Designer. Two developers cannot simultaneously make schema changes to a team solution.
  
  
• Only one workflow process can be defined per user table.
  
  
• There is no debugging support for the workflow script editor. You should use the Logger object to debug your script. For more information, see Logger Object Model Reference in the Reference section.
  
  
• All code must be written in Microsoft Visual Basic® Scripting Edition (VBScript).
  
  
• Workflow status columns must be integer type and must have a foreign key constraint with a keyword lookup table that stores the names of the workflow states. This column can be created using the Workflow Process wizard.
  
  
• Make sure your script has error handling for cases where user directory information is not available. For example, make sure your solution 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. If the names are different (for example, if the action value is “OnUpdate_0” but the associated function in the script block is “Sub OnUpdate_1 end sub”), an unknown name error will occur. This is because the scripting engine cannot find the function entry point in the script block.
  
  
• Stored procedures containing comments at the beginning of the code may cause offline replication to fail. If you have problems with stored procedures, remove the comments, and try again.

For more information about workflow requirements, see The Workflow Engine Model.

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, 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 deleted items

1. Update the record’s state to Null.
   
   
2. Update the record’s state to a new valid state.

In addition, you can disable workflow enforcement, reset your state, and then re-enable workflow.

Recovering workflow after a table name has changed

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

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

Trigger execution order is not guaranteed

In SQL Server 7.0, the order of trigger execution is not guaranteed. If you define one or more triggers for a workflow-enabled table, those triggers may interact unpredictably with the workflow triggers created on that table. For details, see Workflow Trigger Considerations.

Workflow Process pane may not refresh automatically

In the Access Workflow Designer, the Workflow Process pane may not refresh automatically when you add new main tables using the Main Table Selection wizard. Even pressing F5 for manual refresh may not refresh the pane.

To work around this problem, close and reopen the Workflow Process pane to update the pane.

Access to modwfe.log used for workflow script debugging on the server is not by default

Members of modAppOwners NT group have the permissions required to develop team solutions. However, if you are attempting to debug workflow-scripting code on the production server, you must have access to the modWFE.log, which is located in the system32 directory of the server. 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.