Foreign key errors can also arise when performing update or delete operations. For example, suppose you try to remove the R&D department from the Departments table. The DepartmentID field, being the primary key of the Departments table, constitutes the ONE side of a one-to-many relationship (the DepartmentID field of the Employees table is the corresponding foreign key, and hence forms the MANY side). A record on the ONE side of a relationship may not be deleted until all corresponding records on the MANY side are deleted.
An error is reported indicating that there are other records in the database that reference the R&D department, and the delete operation is not performed.
primary key for row in table 'Departments' is referenced in another table
To remove the R&D department, you need to first get rid of all employees in that department:
DELETE FROM Employees WHERE DepartmentID = 100;
You can now delete the R&D department.
You should cancel these changes to the database (for future use) by entering a ROLLBACK statement:
All changes made since the last successful COMMIT are undone. If you have not done a COMMIT, then all changes since you started Interactive SQL are undone.
Now, suppose you try to change the DepartmentID field from the Employees table. The DepartmentID field, being the foreign key of the Employees table, constitutes the MANY side of a one-to-many relationship (the DepartmentID field of the Departments table is the corresponding primary key, and hence forms the ONE side). A record on the MANY side of a relationship may not be changed unless it corresponds to a record on the ONE side. That is, unless it has a primary key to reference.
For example, the following UPDATE statement causes an integrity error:
UPDATE Employees SET DepartmentID = 600 WHERE DepartmentID = 100;
no primary key value for foreign key 'FK_DepartmentID_DepartmentID' in table 'Employees' is raised because there is no department with a DepartmentID of 600 in the Departments table.
To change the value of the DepartmentID field in the Employees table, it must correspond to an existing value in the Departments table. For example:
UPDATE Employees SET DepartmentID = 300 WHERE DepartmentID = 100;
This statement can be executed because the DepartmentID of 300 corresponds to the existing Finance department.
Cancel these changes to the database by entering a ROLLBACK statement:
In all of the above examples, the integrity of the database was checked as each command was executed. Any operation that would result in an inconsistent database is not performed.
It is possible to configure the database so that the integrity is not checked until commit time using the wait_for_commit option. This is useful if you need to make changes that may cause temporary inconsistencies in the data while the changes are taking place. For example, suppose you want to delete the R&D department in the Employees and Departments tables. Since these tables reference each other, and since the deletions must be performed on one table at a time, there will be inconsistencies between the table during the deletion. In this case, the database cannot perform a COMMIT until the deletion finishes. Set the wait_for_commit option to On to allow data inconsistencies to exist up until a commit is performed. See wait_for_commit option [database].
You can also define foreign keys in such a way that they are automatically modified to be consistent with changes made to the primary key. In the above example, if the foreign key from Employees to Departments was defined with ON DELETE CASCADE, then deleting the department ID would automatically delete the corresponding entries in the Employees table.
In the above cases, there is no way to have an inconsistent database committed as permanent. SQL Anywhere also supports alternative actions if changes would render the database inconsistent. See Ensuring Data Integrity.