It's an interesting question thst you might test by trying it out.
I think, however, that this one is best done via PSOS.
I haven't run a true test with time capture, but the delete happens so fast when performed by the client that there's no need adding the additional code to do a PSoS. I mean, it's instant. Very cool.
1 of 1 people found this helpful
I believe that FileMaker handles cascading deletes. One key thing to remember is that a cascading delete is NOT context sensitive. So if you are on a layout based on a TO with a different name but the base table is the same as the one where you set up the cascading delete. When you delete the record you are on, it will delete the child records as well. Even if the child tables are NOT connected to the table occurrence you are on.
First time I set this up, I thought I had to be on the correct layout/table occurrence. Then records started to disapear from the child table when I didn't expect it.
Once I understood how this worked, I find it very helpful/useful. Just be very careful about when you set these up.
Ditto that. I was aware of the context issue which, actually, was what made the concept so interesting. Find and delete one record and your done. Previously, I had to go to a layout for each table, find the relevant items, delete them, and repeat.
The amount of time needed to process cascading deletes will be a function of the total number of records in the tables and the number of records you are deleting on the "other" side of the relationship. Thus, it's extremely important to test this on real world numbers of records in the same client server set up if you are concerned about performance.
And given the fact that any one of possibly dozens of relationships linking your two tables might be the one that enables the cascading delete, I recommend adding a text box to your relationships graph to use solely for documenting each relationship where "delete" has been enabled. That gives you a single, central place to check if concerns about cascading deletes arise.
Cascading deletes are a very powerful tool for maintaining good data integrity, but like any powerful tool, it also has the power to commit total havoc on your data so it must be used (and documented!) with care.
thoroughly test cascading deletes before you go to prod or you may end up deleting stuff you need
Thanks for the tips. I think my saving grace is an extremely simple relationships graph. It's a perfect tree such that when I delete any node on the tree, I know I will only be deleting related items below that node. I did make a comment on the graph indicating that the deletes are all one way and pointed down the tree,
Not sure my use of words here clearly explains, but again, a simple graph is the key element here.
very clear and very good advice, RussW!