DELETE ACTIONS
- None
- Cascade
- Restricted
- Cascade+Restricted.
A. None
Cascade
Restricted
Cascade+Restricted.
To maintain data integrity we will use delete actions
Delete actions will come in to picture when user is trying to delete a record [Alt + f9]
Delete actions will come in to picture when user is trying to delete a record [Alt + f9]
Cascade: Setting the DeleteAction property to Cascade extends the functionality of the table's delete method. As a result, super(), in delete, initiates a cascaded deletion, propagating the delete from table to table.
A cascaded delete is implicitly protected by tts. Database changes aren't committed until the entire transaction is complete.
This cascading will take place whether the deletion is performed in code or directly by a user through the user interface.
Ex: On the CustTable table, a cascading delete action has been defined for the CustBankAccount table. When a customer is deleted from the CustTable table, the delete method also ensures that the corresponding bank account information is automatically deleted.
Restricted: While deleting a record, If the record having any transcations then a warning message will appear. If the record is not having any transactions in another table then only deleted.
Restricted
Setting the DeleteAction property to Restricted extends the functionality of the table's validateDelete method.
As a result, super(), in validateDelete, checks whether records exist on related tables. If records do exist, validateDelete returns false. The forms system ensures that the deletion is not performed. In your own X++ code, check the return value of validateDelete. Don't delete the primary or related records if the method returns false.
Ex:On the CustTable table, a restricted delete action has been defined for the CustTrans table. When a customer is deleted in the CustTable table, the validateDelete method ascertains whether transactions exist for the customer in the CustTrans table. If so, validateDelete returns false.
Cascade + Restricted: Setting the DeleteAction property to Cascade+Restricted extends the functionality of the table's validateDelete and delete methods.
As a result, super(), in validateDelete, ascertains whether records exist on related tables. Whether deleting records from forms or X++, if validateDelete returns false, the primary record isn't deleted and the cascading delete isn't performed. You should first delete the records in the related table before deleting the primary record.
If the primary record is being deleted as part of a cascading delete, the primary record and the records in the related table will be deleted.
Reference
Ex.The Cascade+Restricted delete action is used in the standard application for LedgerJournalTrans on LedgerJournalTable. This type of delete action is useful when you prefer a total clean-up—when you delete a customer, you also delete all the transactions associated with that customer.
e.g.: tableA (Customer) (a cascade deleteaction to tableB) tableB (SalesOrder) (a cascade+restricted deleteaction to tableC) tableC (SalesLine)
When a record of tableB will be deleted, the restricted part of the deleteaction will be performed. The record of tableB can only be deleted, if no record in tableC exist for the record in tableB. (The SalesOrder can only be deleted, if no SalesLine exist for the SalesOrder).
A record in tableA will be deleted, so the cascade deleteaction to tableB will be performed. In this case, the cascade part of the deleteaction to tableC will be performed. (When a Customer will be deleted, the SalesOrders and SalesLines will also be deleted)
None - nothing
Cascade - both tables are deleted via code and front end.
Restricted - via form -> error , if you try to delete via code only second table will get deleted.In case you use validatedelete() then you will get errror.
C+R : in both cases both deleted. No error is raised (diff)
A cascaded delete is implicitly protected by tts. Database changes aren't committed until the entire transaction is complete.
This cascading will take place whether the deletion is performed in code or directly by a user through the user interface.
Ex: On the CustTable table, a cascading delete action has been defined for the CustBankAccount table. When a customer is deleted from the CustTable table, the delete method also ensures that the corresponding bank account information is automatically deleted.
Restricted: While deleting a record, If the record having any transcations then a warning message will appear. If the record is not having any transactions in another table then only deleted.
Restricted
Setting the DeleteAction property to Restricted extends the functionality of the table's validateDelete method.
As a result, super(), in validateDelete, checks whether records exist on related tables. If records do exist, validateDelete returns false. The forms system ensures that the deletion is not performed. In your own X++ code, check the return value of validateDelete. Don't delete the primary or related records if the method returns false.
Ex:On the CustTable table, a restricted delete action has been defined for the CustTrans table. When a customer is deleted in the CustTable table, the validateDelete method ascertains whether transactions exist for the customer in the CustTrans table. If so, validateDelete returns false.
Cascade + Restricted: Setting the DeleteAction property to Cascade+Restricted extends the functionality of the table's validateDelete and delete methods.
As a result, super(), in validateDelete, ascertains whether records exist on related tables. Whether deleting records from forms or X++, if validateDelete returns false, the primary record isn't deleted and the cascading delete isn't performed. You should first delete the records in the related table before deleting the primary record.
If the primary record is being deleted as part of a cascading delete, the primary record and the records in the related table will be deleted.
Reference
Ex.The Cascade+Restricted delete action is used in the standard application for LedgerJournalTrans on LedgerJournalTable. This type of delete action is useful when you prefer a total clean-up—when you delete a customer, you also delete all the transactions associated with that customer.
e.g.: tableA (Customer) (a cascade deleteaction to tableB) tableB (SalesOrder) (a cascade+restricted deleteaction to tableC) tableC (SalesLine)
When a record of tableB will be deleted, the restricted part of the deleteaction will be performed. The record of tableB can only be deleted, if no record in tableC exist for the record in tableB. (The SalesOrder can only be deleted, if no SalesLine exist for the SalesOrder).
A record in tableA will be deleted, so the cascade deleteaction to tableB will be performed. In this case, the cascade part of the deleteaction to tableC will be performed. (When a Customer will be deleted, the SalesOrders and SalesLines will also be deleted)
None - nothing
Cascade - both tables are deleted via code and front end.
Restricted - via form -> error , if you try to delete via code only second table will get deleted.In case you use validatedelete() then you will get errror.
C+R : in both cases both deleted. No error is raised (diff)
No comments:
Post a Comment