Removing rows from tables with referential

constraints
If a table has a primary key but no dependents, or if a table has only foreign keys but no primary
key, the DELETE statement operates the same way as it does for tables without referential
constraints. If a table has a primary key and dependent tables, the DELETE statement operates
according to the delete rules specified for the table.

All delete rules of all affected relationships must be satisfied in order for the delete operation to
succeed. If a referential constraint is violated, the DELETE operation fails.

The action to be taken on dependent tables when a DELETE is performed on a parent table
depends on the delete rule specified for the referential constraint. If no delete rule was defined,
the DELETE NO ACTION rule is used.

DELETE NO ACTION
Specifies that the row in the parent table can be deleted if no other row depends on it. If a
dependent row exists in the relationship, the DELETE fails. The check for dependent
rows is performed at the end of the statement.
DELETE RESTRICT
Specifies that the row in the parent table can be deleted if no other row depends on it. If a
dependent row exists in the relationship, the DELETE fails. The check for dependent
rows is performed immediately.

For example, you cannot delete a department from the department table if it is still
responsible for some project that is described by a dependent row in the project table.

DELETE CASCADE
Specifies that first the designated rows in the parent table are deleted. Then, the
dependent rows are deleted.

For example, you can delete a department by deleting its row in the department table.
Deleting the row from the department table also deletes:

 The rows for all departments that report to it

 All departments that report to those departments and so forth.

DELETE SET NULL

Specifies that each nullable column of the foreign key in each dependent row is set to its
default value. This means that the column is only set to its default value if it is a member
of a foreign key that references the row being deleted. Only the dependent rows that are
immediate descendents are affected.
DELETE SET DEFAULT
 Specifies that each column of the foreign key in each dependent row is set to its default
value. This means that the column is only set to its default value if it is a member of a
foreign key that references the row being deleted. Only the dependent rows that are
immediate descendants are affected.

For example, you can delete an employee from the employee table (EMPLOYEE) even if
the employee manages some department. In that case, the value of MGRNO for each
employee who reported to the manager is set to blanks in the department table
(DEPARTMENT). If some other default value was specified on the create of the table,
that value is used.

This is due to the REPORTS_TO_EXISTS constraint defined for the department table.

If a descendent table has a delete rule of RESTRICT or NO ACTION and a row is found such
that a descendant row cannot be deleted, the entire DELETE fails.

When running this statement with a program, the number of rows deleted is returned in
SQLERRD(3) in the SQLCA. This number includes only the number of rows deleted in the table
specified in the DELETE statement. It does not include those rows deleted according to the
CASCADE rule. SQLERRD(5) in the SQLCA contains the number of rows that were affected
by referential constraints in all tables. The SQLERRD(3) value is also available from the
ROW_COUNT item in the GET DIAGNOSTICS statement. The SQLERRD(5) value is
available from the DB2_ROW_COUNT_SECONDARY item.

The subtle difference between RESTRICT and NO ACTION rules is easiest seen when looking
at the interaction of triggers and referential constraints. Triggers can be defined to fire either
before or after an operation (a DELETE statement, in this case). A before trigger fires before the
DELETE is performed and therefore before any checking of constraints. An after trigger is fired
after the DELETE is performed, and after a constraint rule of RESTRICT (where checking is
performed immediately), but before a constraint rule of NO ACTION (where checking is
performed at the end of the statement). The triggers and rules occur in the following order:

1. A before trigger is fired before the DELETE and before a constraint rule of RESTRICT
or NO ACTION.
2. An after trigger is fired after a constraint rule of RESTRICT, but before a NO ACTION
rule.