1. Business Process Framework: Workflow Guide
  2. Guidelines for Configuring Database Triggers

Guidelines for Configuring Database Triggers

If you configure the Generate Triggers server component, then it is recommended that you adhere to the following guidelines:

  • If you delete a Workflow Policy, then you must run Generate Triggers with the remove parameter set to TRUE, which removes every database trigger. You must then rerun Generate Triggers to reset the database triggers for the remaining Workflow Policies.

  • If you drop or recreate database task triggers, then you must start a new Workflow Monitor Agent, which refreshes the cache for this agent.

  • If you change a Workflow Policy condition or a Workflow Policy group, then you must rerun Generate Triggers. It is not necessary for you to rerun Generate Triggers if you change a Workflow Policy action. For more information, see Moving a Workflow Policy to a Different Group.

  • If your configuration uses a SQL Server, then make sure you set your default database correctly. To determine your default database, start the SQL Server Enterprise Manager, and then navigate to the SQL Server Machine name. Next, click Security, and then click LOGIN. The default database is listed.

  • If a table name exceeds the <maximum length>, then Generate Triggers fails with an error that is similar to the following: 

    # character limit, table_name trigger fail

    To prevent this from happening: set EXEC=FALSE when you generate the triggers with the GenTrig component, manually edit the trigger name in the generated SQL file, and then run the SQL script file manually.

  • If you run Generate Triggers, then the limit on table names that DB2 SQL uses results in limiting the database trigger name to <maximum length>. Siebel CRM derives the database trigger name from the (length of table name) plus a (suffix), such as U, I, D, U1, I1, D1, and so on.