Skip to content

Delete Operations in DDOs

A DDO delete is performed by sending Request_Delete to a DDO. In some cases, you will use objects such as data-entry objects (DEOs) to handle the entire delete for you. In other cases, you will need to write custom code to perform the delete. In all cases, the delete process itself is the same.

Request_Delete Message

The Request_Delete message is responsible for deleting a record in the DDO for the main table, updating all parent DDOs (and tables), and possibly deleting all child records.

Two modes of deleting are supported:

  • A delete will delete all related descendant records.
  • Deletes will not be allowed when child records exist.

The property Cascade_Delete_State controls this message.

Cascade_Delete_State is True

If Cascade_Delete_State is true, Request_Delete will attempt to delete the DDO’s record and all descendant records as follows:

  1. Verify that the DDO structure is valid for the cascade delete operation.
  2. Begin Transaction – From this point on, tables are locked (if the database uses table locking) or records are locked as they are found (if the database uses record locking).
  3. Re-Find all required records.
  4. Get Validate_Delete of the main DDO.
  5. If validation fails, cancel operation.
  6. Delete all related descendant records. For each child record:
  7. Send Deleting to the child DDO.
  8. Send Backout to all parent DDOs.
  9. Attach and Save all parent tables (Attach_Main_File, Save_Main_File).
  10. Delete the child record (Delete_Main_File).
  11. Delete the record of the main DDO.
  12. Send Deleting to the main DDO.
  13. Send Backout to all parent DDOs.
  14. Attach and Save all parent tables (Attach_Main_File, Save_Main_File).
  15. Delete the main record (Delete_Main_File).
  16. End Transaction – Either commit changes or roll back changes. Unlock tables.
  17. If delete was successful, send Refresh to all participating DEOs.

Cascade_Delete_State is False

If Cascade_Delete_State is false, Request_Delete will not allow users to delete a record when a child-file record(s) exists as follows:

  1. Verify that the DDO structure is valid for the no-cascade delete operation.
  2. Begin Transaction – From this point on, tables are locked (if the database uses table locking) or records are locked as they are found (if the database uses record locking).
  3. Re-Find all required records.
  4. Get Validate_Delete of the main DDO.
  5. If validation fails, cancel operation.
  6. Check for any child records or closed tables (get Validate_Delete_No_Cascade).
  7. If validation fails, cancel operation.
  8. Send Deleting to the main DDO.
  9. Send Backout to all parent DDOs.
  10. Attach and Save all parent tables (Attach_Main_File, Save_Main_File).
  11. Delete the main record (Delete_Main_File).
  12. End Transaction – Either commit changes or roll back changes. Unlock tables.
  13. If delete was successful, send Refresh to all participating DEOs.

Handling Errors

If an error occurs anywhere within a delete, the transaction is rolled back, the database is unlocked, and the error is reported.

Most often, the error will occur within the Validate_Delete event and will be a “controlled” error (i.e., an error purposefully created by the programmer). This must be a real DataFlex error generated using the UserError message or the Error command. The generation of an error is what triggers a transaction rollback. The reporting of the error will be properly deferred until the transaction is rolled back and your database is unlocked.

Although Validate_Delete is the event specifically created to allow you to perform one last validation, you may stop a transaction within any of the delete events (Deleting, Backout, Delete_Main_File, Attach_Main_File, Save_Main_File). If you generate an error, the transaction will be rolled back.