Finance | Project Operations, Human Resources, ...

Cascade + Restricted delete action in D365FO

(0) Share

Report

Posted on by CU10121822-0

930

Hi team,

I read blog

And found the below context

"Example of Cascade + Restricted
Suppose we have three tables (Person ,

Customer &

Order).

Now Person is a parent of Customer table, and

Customer is a parent of Order table having (One-To-Many) relations –

If I set a Delete action property on Person table (Parent table) to “CASCADE” for customer table and

If I set a Delete Action property on a CUSTOMER table (Parent table) for Order table to “CASCADE +RESTRICTED”.

So if I delete a record from Customer table (Parent table) then It will first check the record in the child table (Order table) and if exist that warning prompt saying that first we need to delete a record from child table.

But if I delete a record from Person table (Parent table)it will automatically delete a record in Customer table and all records related to customer table in Order table would also be deleted.

Here my question is :

How order table record will delete?

It has delete action “cascade+restricted”

Pls advise, thanks

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Martin Dráb 240,571 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

You correctly stated that it'd be deleted. I don't understand what you mean by asking how it will delete. Please explain what you mean by that.

Note that the usual approach in F&O is using the On Delete action on a table relation, rather then using delete actions. For example, if you add a custom table with a relation to CustTable, you don't need to modify CustTable anymore; you simply create a relation in your table and set the delete action there.

By the way, I see we already discussed Cascase + Restricted delete actions in your older thread Delete action cascade + restricted in d365fo.

Was this reply helpful? Yes No
CU10121822-0 930 on at

Like (0)

Report
Copy link

Link copied!

Yes Martin, I agreed I posted before also. I confused…
Just confirm me, which thread approach is correct? I will follow that.
Pls advise, thanks

Was this reply helpful? Yes No
Martin Dráb 240,571 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Well, I still don't what your question here and therefore whether it matches the topic of the other thread.

That you gave them both threads (almost) the same name might mean that it's a single topic, but it's also possible that you just didn't set names correctly. The title isn't very specific.

I also see that you still haven't verified any answer in your old thread, which may mean that you still have some question, but maybe you forgot to do that.

That you created a new thread may mean that you consider it a different topic, but maybe you just forgot about the thread you created a month ago.

I can only guess what you had in mind when you created this new thread. It's you who must explain that.

Was this reply helpful? Yes No
Suggested answer

Aps10 79 on at

Like (0)

Report
Copy link

Link copied!

Cascade + Restricted behaves differently depending on how the delete was triggered — that's the part that's easy to miss.
Delete the Customer record directly and it acts as Restricted: you're blocked if Order records exist.
Delete the Person record instead, and the Customer deletion happens as part of a cascade rather than as a direct delete. In that case it acts as Cascade, so the Order records are deleted too.
So both behaviours you described are correct — they're just two different entry points. The reason the combination exists is precisely this: block someone deleting a Customer by hand while Orders exist, but don't let that block break a legitimate cascade coming down from Person. Otherwise the Person cascade would fail every time a Customer had orders.
Building on Martin's point, which matters more in practice than the semantics: set the delete action as On Delete on a relation in your own table rather than on the standard parent. Same behaviour, and you never touch CustTable.

Was this reply helpful? Yes No