None of the schedules are executing automatically. However, if started manually they are executed successfully. The DBQueue processor seems to work normally.
This may be due to product defect (26930).
It may be due to entries in DialogScriptAssemblies: The compiler does not remove DialogScriptAssemblies of deactivated tables. A preprocessor condition is active and therefore the DialogScriptAssemblies for these tables with these pre-processor conditions are available in the database. Now the preprocessor condition is switched off and a comprehensive compilation is executed. The ScriptAssemblies for the now deactivated tables are not deleted. This may not immediately result in an issue, but the affected entries will be set to IsValid=0 after some time and this will result in an issue with functionality. For example, DialogSchedules are not executed because PscheduleCheck checks if there are ScriptAssemblies with IsValid=0.
Activate the appropriate pre-processor condition. To do so Execute a comprehensive Compilation of the database.
1. Execute the following SQL Statement in SQL Server Management Studio to verify that you have the issue described in this article:
SELECT * FROM DialogScriptAssembly
WHERE isvalid = 0
2. Delete these entries:
Please be sure you have a valid database backup!
Delete FROM DialogScriptAssembly
WHERE isvalid = 0
3. Recalculate the “next run date” of all schedules:
4. Check if “next run date” of the schedule is now in the future:
select NextRun, * from DialogSchedule
where uid_DialogSchedule = 'QBM-7643036794b545f4b34646813f4b50xx'
5. Execute a comprehensive Compilation of the database.
Please ensure you have a valid database backup available before running any SQL statements on the Identity Manager database.
This has been fixed in versions 7.1.1 and 7.0.3. If you require this immediately corrected, please contact Support for a hotfix referencing the defect ID 26930.