Description
By default, this is always False. Adding Set ParentNullAllowed to True in the DD class or object specifies that this is a candidate for a Null parent. This is set in a child DD to affect the parent DD.
For example adding the following to the order DD (in program Order.src in the Order sample workspace)
Object OrderHea_DD is a OrderHea_DataDictionary
Set DDO_Server to SalesP_DD
// other code
Set ParentNullAllowed SalesP.File_Number to True
End_Object
would make sales person optional.
If set, you would get the following changed behaviors:
1. If the DEO field for Saleperson ID is blank and AutoFind is specified, autofind will clear the DDO (see Request_ClearBindingTable) instead of finding a record.
2. If the field is Find-Required but it is cleared, it will not raise a find required error.
3. When saved, the salesperson DD record will not be saved. It does this as follows:
3a. It will receive the Entry_Update message so data will be moved from the DD buffer to the file buffer. Normally, these kinds of parent fields will be No-Put, so there will be no change.
3b. If the parent DD is new and there are no changes in its file buffer, it will call IsNullParentAllowed in the child DD (order), passing the table number of the null parent candidate (SalesP).
3c. The DD's IsNullParentAllowed has been augmented to check if null is allowed. It checks if you've set this as a null candidate via Set ParentNullAllowed.
3d. If IsNullParentAllowed is True, the parent will not be part of the save and and the runtime it will not call Creating, Update, Validate_Save, Attach_Main_File or Save_Main_File.
For the most part, you will control this via Set ParentNullAllowed and that's it. IsNullParentAllowed is suitable for augmentation.
You are allowed to edit a child and change a parent record from null to a real record and back.
Expected Use
There is an expected way this will be used. We expect that this will be a parent which will be used in the traditional way a foreign DD is used within a view - the record is selected by finding via the parent key and all other non-indexed fields displayed for the parent will be displayonly. Most likely it will find via autofind and it will be find-required. In this environment, you are not allowed to save a new parent within a child view (i.e., you do not create new parent Customer or SalesP records when adding / editing an order record). This is the environment that this has been designed for. If you do something more exotic, you may not be able to use this feature.
Orphaned Records
Caution: Setting ParentNullAllowed to True will allow you to create orphaned child records (child records without a corresponding parent record). Depending on your business/database rules, this may be undesired or even prohibited. For example, if you are using an SQL database, changing this setting at the Data Dictionary level might not enable a child record with a null parent to be added to a table, because the SQL database might have a constraint (e.g. foreign key constraint) or a combination of them defined for the table that will not allow a record for the child table to be created without specifying a value for the column even when ParentNullAllowed is true.
CascadeDeleteNull allows child DDs to specify if they should be deleted or have their child to parent relationship set to null.
An alternative would be to create a "null" record in the parent, which can be used in lieu of allowed null parents. For example, you could create a parent record with an Id column value of "NONE" or something like it.
See Also
ParentNoSwitchIfCommitted