-
Book Overview & Buying
-
Table Of Contents
IBM DB2 9.7 Advanced Application Developer Cookbook
By :
The AUTO_REVAL database configuration parameter controls the revalidation and invalidation semantics in DB2 9.7. This configuration parameter can be altered online without taking the instance or the database down. By default, this is set to DEFERRED and can take any of the following values:
IMMEDIATEDISABLEDDEFERREDDEFERRED_FORCENow that we know all of the REVALIDATION options available in DB2 9.7, let's understand more about the CREATE WITH ERROR support. Certain database objects can now be created, even if the reference object does not exist. For example, one can create a view on a table which never existed. This eventually errors out during the compilation of the database object body, but still creates the object in the database keeping the object as INVAILD until we get the base reference object.
First, we will look at the ways in which we can change the AUTO_REVAL configuration parameter.
UPDATE DB CFG FOR <DBNAME> USING AUTO_REVAL [IMMEDIATE|DISABLED|DEFERRED|DEFERRED_FORCE]
CREATE WITH ERROR is supported only when we set AUTO_REVAL to DEFERRED_FORCE and the INVALID objects can be viewed from the SYSCAT.INVALIDOBJECTS system catalog table.
AUTO_REVAL to DEFERRED_FORCE.UPDATE DB CFG FOR SAMPLE USING AUTO_REVAL DEFERRED_FORCE
v_FMSALE, referring to the FMSALE base table. Since we do not have the base table currently present in the database, DB2 9.7 still creates the view, marking it as invalid until we create the base reference object. This wasn't possible in the earlier versions of DB2.CREATE VIEW c_FMSALE AS SELECT * FROM FMSALE
SYSCAT.INVALIDOBJECTS, shows why the database object is in an invalid state:SELECT OBJECTNAME, SQLCODE, SQLSTATE FROM SYSCAT.INVALIDOBJECTS

When we create an object without a base reference object, DB2 still creates the object with a name resolution error such as the table does not exist (SQLCODE: SQL0204N SQLSTATE: 42704).
(SQLCODE: SQL0206N SQLSTATE: 42703). SQLCODE: SQL0440N SQLSTATE: 42884. AUTO_REVAL is set to IMMEDIATE, all of the dependent objects will be revalidated as soon as they get invalidated. This is applicable to ALTER TABLE, ALTER COLUMN, and OR REPLACES SQL statements. AUTO_REVAL is set to DEFERRED, all of the dependent objects will be revalidated only after they are accessed the very next time; until then, they are seen as INVALID objects in the database. AUTO_REVAL is set to DEFERRED_FORCE, it is the same as DEFERRED plus the CREATE WITH ERORR feature is enabled.Let's have a quick look at the difference between AUTO_REVAL settings and behavior.
Case 1: AUTO_REVAL=DEFERRED
T1, on which the view V1 depends, is dropped, the drop would be successful, but V1 would be marked as invalid. T1, V1 would still be marked as invalid until explicitly used.Case 2: AUTO_REVAL=DEFERRED_FORCE
AUTO_REVAL to DEFERRED_FORCE.
Change the font size
Change margin width
Change background colour