How DELETE Statements are Handled

See Also

A SQL statement that deletes records from any table of a subtype constellation (assuming supertype and subtype object data are stored in separate tables), is considered to be a delete in the whole constellation but only if, for the subtype table, option "Delete Super on Delete" is set to active (in the Definer). If this is the case, deleting the subtype record causes its supertype counterpart to be deleted, which in turn will trigger cascading deletes to other subtype records the supertype record is the supertype record of.

These data manipulations are only allowed to take place if appropriate rights have been specified in the Authorizer.

If option "Delete Super on Delete" is set to 'NO', a delete of a subtype record actually causes an update to be executed on the supertype table (the indicator column is set to 'N'). So depending on the kind of settings made in the Definer, you must specify different kind of access rights in the Authorizer.

NOTE:

It does not make any difference whether supertype and subtype object data are physically stored in one, or in separate tables: the delete of the subtype record actually causes an update to be executed on the supertype table in either case (only the number of updated columns is different: just the subtype indicator column vs. the subtype indicator column and the subtype object data columns). In order to allow the end-user to delete subtype specific data, you need to specify the right to delete and update (for an explanation refer to "How UPDATE Statements are Handled") the subtype table (although this table may physically not exist), and you need to specify the right to update the supertype table (or at least the right to update the appropriate subtype indicator column in the supertype table).