Skip to content

Deletes - Request_Delete

A    B    C
\ /    /
D    E
\ /
F
/ \
G    H

A Request_Delete attempts to delete the record from the DDO’s main table.

If the Cascade_Delete_State property is true, and there are child-table DDOs in the Data Dictionary structure with a defined relationship between the child and parent tables, the DDO will also delete the child records. This process will recurse down the Data Dictionary structure. Although a Request_Delete cannot delete a parent-table record, it can update a parent table. This means that a Request_Delete will propagate up and down the Data Dictionary structure.

If the DDO’s Cascade_Delete_State property is false, the DDO will not delete a record to which record(s) in child table(s) relate. Therefore, if a delete occurs, the propagation direction will be up (just like a save).

  • Deletes with cascade deletes propagate up and down.
  • Deletes with no cascade deletes propagate up.

Example Scenarios

  • If a Request_Delete were sent to Object H_DD, the record in table H would be deleted, and tables A, B, C, D, E, and F would be updated.

  • A delete request sent to Object A_DD (if its Cascade_Delete_State is true) would:

  • Delete a record in A,
  • Delete all of A’s child records in D,
  • Delete all of D’s child records in F,
  • Delete all of F’s child records in G and H.

Deleted D records would update table B. Deleted F records would update E and C. In other words, every DDO in the table structure would be affected by a delete in A.

This suggests that you must have a complete data-server dictionary in place to delete records in a parent table. If you want automatic deletions of child-table records, this is true. Often, you will want to prohibit deletes if there are child-table records relating to the main-table record. You can use the Cascade_Delete_State property to protect against this. If you disallow deletions of records that have children, deletes will act the same as saves and only propagate up the Data Dictionary structure.

This will determine how complete your Data Dictionary structure needs to be represented inside a view. If you need a view that can save and delete records from table A (it might be a vendor table) and you are disallowing deletes if child records exist, the only DDO that will be required in your view is A_DD. If you wish to be able to delete all child records, you will need the complete Data Dictionary structure.

Important Considerations

A few things about deletes should be emphasized:

  • The table that a record is deleted from is determined by the DDO and not the DEO that sent the message. The record will be deleted from the receiving DDO's main table.
  • The propagation of deletes down to child records is determined by the DDO_Server updating structure and the relationships in the tables’ definitions. If either is missing, the child deletes will not occur.
  • Relates-to constraints have absolutely no effect on the delete process.

See Also