I want to be able to delete a record from Table A, but also have all of it's related records from Tables B and C deleted as well.  Is there an easy way to do this, or do I need a delete button or menu option to go to a layout of each table, find the records based on the ID from Table A, and delete them?  Thanks for the help!

edit the relationship and turn on delete checkbox that will delete records in child when records in parent is deleted. 

(backup before you test)

 

Oh duh, perfect!  And that works even if data is not contained in a portal?  Thanks!

Yes, this is called a cascading delete and doesn't require a portal or any of the child fields on the layout (Portals are UI display elements). Often, developers create a separate set of table occurrences that have the delete check on, and only those TOs have the delete. Some devs. color those TOs red. Deleting can be a big deal... depends on the workflow.

However, watch for data integrity. Sometimes, it is preferred to NOT delete a child element. Sometimes, a "soft" delete is preferred (simply marking the record as deleted and filtering it from views).

4 minutes ago, bcooney said:

Often, developers create a separate set of table occurrences that have the delete check on, and only those TOs have the delete.

What difference does that make (assuming that these TOs are in the same file)?

Presumably bcooney meant that both the parent and child TO's are repeated, and set to delete via the relationship, and therefore only when you are on a layout based on those new TO's does the cascading delete occur. Provides a way to perform that function for the developer, without risking it happening inadvertently from the main TO's used in the solution. Maybe?

32 minutes ago, rwoods said:

Presumably bcooney meant that both the parent and child TO's are repeated, and set to delete via the relationship, and therefore only when you are on a layout based on those new TO's does the cascading delete occur.

The reason I am asking is that such assumption would be incorrect.

So you are saying that 'delete child records' is independent of the layout that you are on at the time? So that delete fires if *any* relationship between TO's based on those tables has the 'delete child records' option set, regardless of which layout you are on at the time?

Edited May 31, 20196 yr by rwoods

14 minutes ago, rwoods said:

So you are saying that 'delete child records' is independent of the layout that you are on at the time? So that delete fires if *any* relationship between TO's based on those tables has the 'delete child records' option set, regardless of which layout you are on at the time?

I am saying even more than that. I was recently shown a solution where the "deleting TOG" was in another file. The way they controlled whether the cascading delete should happen or not was by opening or closing the other file.

Yes, rwoods is correct. I was mentioning an approach to manage deletes that I’ve read about and have not used. A separate set of delete tables occurrences. 

So, comment, there are faults with that technique?

I think the only reason why some developers create mirror TOGs (one set with "cascading deletes" enabled ) is by no means intended to limit the effects of this feature/function - but only has a memory /graph management so if you need to disable cascade deletion when doing mass data acrobatics  you only need to toggle the check box these sets of TOGs and not have to open every other relationship or add text objects adjacent to each relationship as a note.

 

 

24 minutes ago, bcooney said:

So, comment, there are faults with that technique?

It doesn't work (at least not as suggested by @rwoods).  I would tend to consider that as a fault.

@Ocean Westthat makes sense.