Delete Data in the Database (Delete)

Records are first temporarily and then finally deleted. This two-step process protects your data from unintentional delete operations. The trash-basket is used as buffer for temporarily deleted data. It is an iconified mask and can be opened with a mouse-click.


Delete Records Temporarily

The figure shows the functional sequence for deleting records temporarily. The triggering function is the Select function iwf_edt_lis (delete), the Pre_ and Post_Action triggers of the original mask are passed through. If you delete several records at once, all triggers will be passed through several times. If you install your own userexits at the Pre_ or Post_Action trigger, for instance to perform special queries or checks within the functional sequence, you can evaluate the default parameter pr1 automatically passed by triggers. It informs about the current internal work mode of the mask (here T for Temporary) and the current line number.

Attention! Application-specific checks on whether a record may be deleted must always be executed at the Pre_Action trigger prior to the actual temporary deleting.


Lock Temporary Delete Event for Individual Masks

If you defined an event in your application that triggers temporary deleting data via iwf_del_lis, this operation is possible in each active mask, as opposed to mask-specific items or buttons defined for that. In order to lock the delete function for individual masks you can install cch_nop_del at the Pre_Action trigger of these masks. This userexit prevents all temporary delete operations.


Roll Back Records or Delete Finally

The figure shows the functional sequence for rolling back (restore) or deleting data in the trash-basket finally. As an alternative for the item Empty trash-basket in the trash-basket itself you can use the standard menu userexit wdh_del_tra as the triggering function to delete data finally. In DataView it is defined for the key-combination [Shift+Delete]. The Pre_ and Post_Action triggers of the original mask are passed through. If you roll back or finally delete several records at once, all triggers will be passed through several times. If you install your own userexits at the Pre_ or Post_Action trigger, for instance to perform special queries or checks within the functional sequence, you can evaluate the default parameter pr1 automatically passed by triggers. It informs about the current internal work mode of the original mask (here R for Rollback or D for Delete) and the current line number.


Automatically Deleting Dependent Elements

If you delete master records, DataView will automatically delete all assigned relation records which would make no sense without the parent or child element in order to -> secure referential integrity. These relation data are additionally displayed in the trash-basket after a temporary delete process. If the parent or child element is rolled back, they will also be restored in their original masks. The same security procedure applies if temporarily deleting a record triggers the recursive deleting of large relational structures because of the settings for check flags and delete flags.