Reference fields save development time by allowing validations & error messages, help text, triggers and multilingual definitions to be copied from the field being referenced. Once copied from the reference field, they may be modified to suit the new field's specific requirements.
Using a reference field is similar to using the copy facility when creating a new field, except that the link to the reference field remains. Subsequent changes to a reference field automatically cause these changes to be made to the fields that reference it.
A change needs only to be made to the reference field, if the change is required to the:
Reference fields are commonly used for dates.
Most applications have dates: Start Date, Birth Date, Application Date, Closing Date, Delivery Date and so on. If all the dates reference a field called DATE, then the specific validations and error messages relating to the date can be copied from the DATE field. If all the dates are to be within, say, 60 days of the current date except Birth Date, then you create, for Birth Date, the specific range validations required. Should the date field change in size, such as the YY of the year to YYYY, then only the DATE field needs to be changed. (Naturally, report and screen changes resulting from such a change need to be handled in the traditional manner.)
A reference field cannot be deleted while there are fields still referencing it. However, for additional security, reference fields should be defined as System Fields. System Fields cannot be deleted. (The System field option is on the Create/Change Data Dictionary screen). To delete a System Field, you must first change this option to NO.
Before any development is commenced, and particularly if you are extending a non-LANSA application, consideration should be given to all reference fields likely to be required, to ensure that they provide the maximum benefit to the application's developers.