Note: It should be understood that automatic updates or deletions are optional, and can be individually reviewed and decided upon.
Relationships between rows are the basis for most of the "smart" functionality in InstEd. They allow cascaded updates and deletes, provide the basis for the Component, Feature and Dialog treeviews, and allow fast navigation between related rows.
The relationships can be enabled by ensuring that the Enable Row Reference Tracking checkbox is ticked.
Once the rows have been analysed, when you select a row, its relationships will be displayed in the Row Relationships window at the bottom of the main window.
Rows involved in a relationship are identified by their Table name, and a string consisting of all the key fields separated by the "|" character.
Relationships between rows have several properties that determine how they affect the "smart" behaviour.
The various properties are Direction, Ownership, Referencing Fields (refing), Referenced Fields (refed), and whether the relationship is required or optional.Direction
The Direction is indicated by an arrow. An arrow pointing to the right indicates that the row that is selected in the table references the row listed in the Relationships window.
An arrow pointing to the left, indicates that the row selected in the table, is referenced by the row listed in the Relationships window.
The direction of the relationship affects what happens when a field involved the relationship is changed.
The simple rule is, if a row is referenced, changing it updates all the rows that reference it. If a row is referencing, changing it affects only itself.
For example:
If a Component row is referenced by a File row, changing the Component field value of the Component row will cause the File row to be updated, so that it still belongs to the component. This maintains database integrity.
However, changing the Component_ field value of the File row, will not change the referenced Component row, because the user is most likely wanting to make the File row belong to a different Component.
Again, changing a referenced row will update all the referencing rows. Changing a referencing row, will not change the referenced row.
Ownership
Ownership affects what happens when a row is deleted.
When a row that owns another row is deleted, then the rows that are owned by it are deleted as well. For example, deleting a Component row will delete all the File, Registry, ServiceInstall, etc rows that it owns.
Deleting a row that is owned, will not delete the owning row.
In a relationship description, the way that the ownership is phrased will depend on the direction of the relationship. The description always lists the referencing fields first. So if the referencing row owns the referenced row, the description will be of the form: referencing field OWNS referenced field.
For example: Feature.Feature OWNS FeatureComponents.Feature_
If the referenced row owns the referencing row, the description will be of the form: referencing field IS OWNED BY referenced field.
For example: File.Component_ IS OWNED BY Component.Component
More than one row can own any given row. For example, a FeatureComponents row can be owned by both a Feature and a Component row. Deleting either of the owning rows will delete the owned row.
Similarly, any given row can own more than one other row. For example, a Component row can own many File, Registry or other similar rows. Deleting the Component row will delete all the owned rows.
Referencing and Referenced fields
The relationship description will list the fields involved in the relationship. The refing field will always be listed first, and the refed field second.
For example: File.Component_ REFERENCES Component.Component
Occasionally more than one set of fields may be involved in the relationship. This is displayed in the relationship description. For example:
Directory.Dialog REFERENCES Control.Dialog_ + Dialog.Control_Default REFERENCES Control.Control
Required
The relationship description will declare whether the relationship must be satisfied for the database to be valid. For example, a FeatureComponents table row must reference a valid Component.
Rows for which a required relationship is not satisfied will have the relevant field highlighted. The error can be displayed by right clicking the field, and selecting "Show Errors".
Relationships which are not required are marked as optional.
Formatted fields
Some fields will be of type Formatted (or similar) which reference other rows from within string fields using various forms of the [Property/File/Component] notation. These relationships are also maintained. The relationship description for these rows will be simply "Formatted".
References to properties in formatted fields will be interpreted as references to either the Property or Directory tables.