Property Boolean pbNoCascadeDeleteStrict
| Read Access: | Get pbNoCascadeDeleteStrict to BooleanVariable |
| Write Access: | Set pbNoCascadeDeleteStrict to BooleanVariable/Value |
The pbNoCascadeDeleteStrict property determines if your Data Dictionary (DD) operates under strict or non-strict rules. Non-strict (False) is the default, which means that existing DDOs will work exactly as they always have.
Relates can either be defined by a table or by the DD. pbUseDDRelates determines if relates are defined by the table (False) or the DD (True). See pbUseDDRelates for more information.
This is really a compatibility mode property. The use of local constraints creates a problem with no-cascade deletes. Currently, a DD with Cascade_Delete_State=False will allow a delete if there are no child records and the DDs are smart enough to test for existing child records without requiring a child DD in the structure. It does this by looking at the table relationships.
Now, if a child DD does not exist, the DDs don't know what to do. They can't even determine if they can just use the table relationships, because there is no child DD to even test pbUseDDRelates. Note that this is not an issue with cascade deletes, because that requires child DDs. So, this issue only applies to no-cascade-delete DDs that did not build the child structure, because it did not need to.
The solution is to provide child DDs for the DDs you may wish to delete. You just need the immediate child DDs and this will tell you enough to know how to proceed. If the child DDs are not there, the DD should not allow the delete, because it doesn't know what to do. This, the strict approach, is the recommended way to proceed for this situation.
The alternate approach is for the DDs to assume that the missing child DD just means that the Table (API) relationships for the child are accurate and that things should work as they always did. This will usually be the case. This is the non-strict approach.