Skip to content

Null Parent Support

Data Dictionaries support the concept of a null parent record. It is the child DDO's responsibility to determine if a parent can be null. The interface for specifying that a parent may be null is:

Set ParentNullAllowed iParentFile to True|False

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. For example, adding the following to the order DD:

Set ParentNullAllowed SalesP.File_number to True

would make the salesperson optional. If set, you would get the following changed behaviors:

  1. If the DEO field for Salesperson ID is blank and autofind is specified, autofind will clear the DDO instead of finding a record. This clear is done with a new DEO message Request_ClearBindingTable.

  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:

  4. If the parent DD is new and there are no changes in its file buffer, it will send the message IsNullParentAllowed to the child DD (e.g., OrderHea), passing the file number of the null parent candidate (e.g., SalesP).
  5. The DD's IsNullParentAllowed function checks if null is allowed for the passed parent file number. It checks if you've set this as a null candidate via Set ParentNullAllowed.
  6. If IsNullParentAllowed is True, the parent will not be part of the save, and at 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. It will all just work.

There is an expected way this will be used. We expect that this will be a parent which is 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 would 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.

This can be defined at the DD class or object level. At the class level, this new option is now modeled in the Structures tab of the Studio's DD modeler.