DDO Structures with a Single Data Dictionary
We will now create a view for customer entry. We will base the view on a single DDO.
A
A = Customer
Implications of Removing Child-file DDOs
What are the implications of removing the child-file DDOs? If you review our Data Dictionary propagation rules, you will note that the only behavior that would propagate down is a delete. Saves propagate up. Since we have no parent tables, this operation will be fine.
If the child-file DDOs are not provided, a delete will not delete any child records. This means that we would end up with "orphan" records (orders). Normally, we do not want this. We will control this in the DDO’s Cascade_Delete_State property, making it impossible to delete customers that have child records.
Completeness of Data Dictionary Structure
How complete does your Data Dictionary structure have to be? Locate the child most-file DDO, which will have a DEO using it. Make sure that all parent-file DDOs are in your structure and properly connected. If not, your saves and deletes may not work properly.
- If you are disallowing deletes of records that have children, you will not need to create any DDOs below the lowest "used" DDO.
- If you are allowing child-record deletes, you must make sure that the child DDOs and all of those DDOs’ updated DDOs are provided and connected.