SET CURRENT REFRESH AGE

Restriction: This topic applies to Windows environments only.

The CURRENT REFRESH AGE value corresponding to ANY (99 999 999 999 999) cannot be used in timestamp arithmetic operations because the result would be outside the valid range of dates.

This command is only supported syntactically by the XDB Server.

Invocation

This statement can be embedded in an application program or issued interactively. It is an executable statement that can be dynamically prepared.

Authorization

None required.

Syntax

Bold text indicates clauses or options that are supported only syntactically.

SET CURRENT REFRESH AGE [=] {numeric-constant | ANY | host-variable}

`numeric-constant`

A DECIMAL(20,6) value representing a timestamp duration. The value must be 0 or 99 999 999 999 999, the microseconds of which is ignored and thus can be any value.

0	Indicates that query optimization using materialized query tables will not be attempted.
99999999999999	Indicates that any materialized query tables identified by the CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION special register may be used to optimize the processing of a query. This value represents 9999 years, 99 months, 99 days, 99 hours, 99 minutes, and 99 seconds.

ANY

Shorthand for 99999999999999.

`host-variable`

A variable of type DECIMAL(20,6) or other type that is assignable to DECIMAL(20,6). It cannot be set to null. If host-variable has an associated indicator variable, the value of that indicator variable must not indicate a null value. The value of host-variable must be 0 or 99 999 999 999 999, the microseconds of which is ignored and thus can be any value.

Note:

Materialized query tables created or altered with DISABLE QUERY OPTIMIZATION specified are not eligible for automatic query rewrite. Thus, they are not affected by the setting of this special register.
Setting the CURRENT REFRESH AGE special register to a value other than zero should be done with caution. Allowing a materialized query table that may not represent the values of the underlying base table to be used to optimize the processing of a query may produce results that do not accurately represent the data in the underlying table. This situation may be acceptable when you know the underlying data has not changed or you are willing to accept the degree of error in the results based on your knowledge of the data.