The warning sub-system is activated by using one of it's functions. Of course the INTEGRITY_WARNINGS table may always be queried manually, but this does not discover any new problems.

All of the warning sub-system functions are designed to be used in the FROM clause of SELECT statements, as if they were tables. Indeed the functions look like tables to the SELECT statement, tables that look exactly like INTEGRITY_WARNINGS -- except that the Resolved and Deferred_To columns are missing. The difference between querying on the INTEGRITY_WARNINGS table directly and querying using the warning sub-system's functions is that the functions update the content of the INTEGRITY_WARNINGS table by executing the the queries in INTEGRITY_QUERIES table. Also, the functions never return rows where the underlying INTEGRITY_WARNINGS row has a non-NULL Resolved value or a Deferred_To time and date that has not yet been reached.

All timestamps, date plus time values, which the warning sub-system updates in the INTEGRITY_QUERIES and INTEGRITY_WARNINGS tables are set to the date and time at which program execution started. So when, say, run_integrity_queries(), is run, all of the new timestamp values in the INTEGRITY_QUERIES and INTEGRITY_WARNINGS rows touched by the execution are identical.

Various warning sub-system functions (or versions of the same function) are supplied to allow easy selection of which queries in which INTEGRITY_QUERIES rows are to be executed, whether all or only some.