A dependent field can be a parent field to a lower-level dependent field. For example, in Dependent List Example, the Style field described could be a parent field to a Model dependent field. This dependent field would then have a list associated with each of the different styles.

Although no limit exists on the number of list dependency levels you can have, a field can never be a parent to a field to which it is already dependent. For example, assume that you have set up four levels of dependent lists:

Product

If you attempted to select Version as the parent for Style, an error message indicates that this relationship is invalid because Style is already a child of Product.

If you delete the list for the parent field or you delete or change the parent field itself, the dependent lists that have been configured must be cleared. Prior to deleting configuration information for any dependent list, a confirmation window opens. If you did not want to remove the dependent lists, you would click No to have your deletion or change undone.

When you change the list for the parent field, the items selected in the dependent fields are cleared if the dependent fields reside in the same table as the parent field. If the dependent fields reside in a foreign table, which is a related table, the items selected in the dependent fields are not cleared.

For example, if the parent field resides in the System Tree Items table and the dependent fields reside in the FRACAS Incidents table, clearing the list for the parent field does not clear the selections made in the dependent fields. Once the foreign table is refreshed, the dependent fields display the items in the new list selected for the parent field.