Schedule Batch Processing with the Application Timer
As an alternative to initiating batch processes by calling batch jobs, you can make the execution of all batch processes within the database dependent on the application timer.
You cannot call jobs from constraints. Therefore, with the application timer you can only schedule batch processing tasks that do not involve imports from, or exports to, external files.
This technique can be used to schedule SQL tasks as well as those parts of import tasks not relying on external files and sets, for instance, calculations.
From the point of view of system maintenance, batch processing is best written against the application timer whenever possible, because in that case, batch processing is defined in the same way as all other processing, i.e. in terms of business rules. No external files or schedulers are used. Batch processing is made as independent as possible from the environment in which USoft is deployed.
A disadvantage of this technique is that the application timer must run continuously. Another disadvantage is that you cannot commit batch processing on a record-per-record basis.
As an example, consider an import task in which for each imported record a number of calculated values must be generated on the basis of data in other tables. Instead of arranging this in import SQL statements, delay processing until midnight, when online processing on the database has stopped.
To schedule import-related batch processing against the application timer:
[,<computed field>, ...]
,<status field> =
(SELECT <computation> [<computation>, ...]
WHERE tt.app_day <> OLD(tt.app_day)
The basic structure of transition settings is:
Transition Table: T_APP_TIME
Fire On Insert: Never
Fire On Delete: Never
Fire On Update: Used Columns