Best Practices for Table Relations
You will get a best practices error if you create a relation on a table but do not add any fields to it.
Relations in the data model must be expressed in relations that are defined on the extended data types of the fields in the tables or explicitly on the tables. Such relations must have the Validate property set to Yes. Multi-field relations must be specified on the table.
A relation should be defined on the table that is holding the foreign key to the relating table.
The system guarantees that data entered in the database fulfills the specified relations.
If a table has a key, the key must be defined by using relations. Such a relation is called the 'self relation'.
The self relation should not be set up in situations where the fields in the key are all foreign keys (such as relations to other tables) - or more specifically, where the last field in the self relation is a foreign key.
Navigational relations are definitions of relations that exist among data in tables where there are no integrity constraints.
Defining a navigational relation benefits the system’s Auto Join system when one form is opened from within another form.
Define navigational relations to make it easy to navigate in the application by using related information.
A navigational relation has the Validate property set to No.
The Auto Join system uses relations that are defined at both the involved tables, which means that you only have to define a navigational relation on the one table to the other to make the Auto Join system work both ways.
Example
The CustTrans relation on the LedgerTrans table is an example of a purely navigational relation.
.gif)
Both tables hold information about TransDate and Voucher, but neither of them are keys that are used for validating the other.
You can open a CustTrans table-based form from a LedgerTrans table-based form. The system will only show the CustTrans records that have the same TransDate and voucher as the LedgerTrans record has in the form from where you started.
The relation also makes it possible to start from the CustTrans table based form located on a record with a particular transDate and voucher and to open a LedgerTrans table based form that will show only the records with the same TransDate and voucher.
The configuration key that is specified for the field in a relation must be the same key, or in the same tree of keys, as the key used for the related field. If the external field in a relationship can be removed, due to configuration key settings, and the field on which the relation is set is not also removed, you will get a best practices warning.