Using the CREATE WITH ERROR support

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:

• IMMEDIATE

• DISABLED

• DEFERRED

• DEFERRED_FORCE

Now 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.

How to do it...

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.

1. 1. Update the database configuration parameter AUTO_REVAL to DEFERRED_FORCE.

   UPDATE DB CFG FOR SAMPLE USING AUTO_REVAL DEFERRED_FORCE
   
   

2. 2. Try to create a view 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
   
   

3. 3. How do you verify if the object is invalid? The following SQL query on the system catalog table, SYSCAT.INVALIDOBJECTS, shows why the database object is in an invalid state:

   SELECT OBJECTNAME, SQLCODE, SQLSTATE FROM SYSCAT.INVALIDOBJECTS
   
   

4. 4. Once you create the base reference object and access the invalid object, DB2 revalidates and marks it as valid.

5. 5. The following screenshot illustrates the sample output for the preceding statements:

How it works...

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).

1. 1. DB2 creates an object even if the reference column does not exist with the error codes (SQLCODE: SQL0206N SQLSTATE: 42703).

2. 2. If the referenced function is not present, we get SQLCODE: SQL0440N SQLSTATE: 42884.

3. 3. When 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.

4. 4. When 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.

5. 5. When AUTO_REVAL is set to DEFERRED_FORCE, it is the same as DEFERRED plus the CREATE WITH ERORR feature is enabled.

There's more...

Let's have a quick look at the difference between AUTO_REVAL settings and behavior.

Case 1: AUTO_REVAL=DEFERRED

1. 1. When the table T1, on which the view V1 depends, is dropped, the drop would be successful, but V1 would be marked as invalid.

2. 2. After creating T1, V1 would still be marked as invalid until explicitly used.

Case 2: AUTO_REVAL=DEFERRED_FORCE

1. 1. One can create an object without having the base reference object present in the database; this only happens when we set AUTO_REVAL to DEFERRED_FORCE.

2. 2. Object revalidation happens when an object is being accessed.