The Data Builder Integrity page for Referential Validation lets you use a different table, view or CursorAdapter for Referential Integrity, Field Validation and Picklist Help (in the Picklist Builder window). This section provides examples of when would you want to do that.
The ability to use three different tables, views or CursorAdapters is provided primarily for use with views and CursorAdapters.
With tables you would almost always use the same table for all three purposes.
When using views and CursorAdapters, however, here are some examples when you would not enter the same view or CursorAdapter name in all three fields:
1. Example 1: You may create several views or CursorAdapters based on the same table but only fill in the Parent RI Cursor for the foreigh keys in one of them. There would be no need to fill in the Parent RI Cursor for more than one because only one will be needed for RI purposes. That is the view or CursorAdapter that must have the ParentPKValue or RI<fieldname> parameter. For the other views and CursorAdapters, you would leave the Parent RI Cursor empty and only fill in the Validation and Picklist Cursors.
2. Example 2: In a client-server application, where you want to minimize resource usage, you may define different views or CursorAdapters for Validation and Picklist use, with each view or CursorAdapter only including the fields that are necessary for that purpose.
3. Example 3: You might want to create a special Picklist with FIND<field name> parameters so that you can use the SQL Find Form. The SQL Find form is brought up just before the Picklist form, letting the Picklist view or CursorAdapter cursor contain just a subset of records. This is particularly useful when the Picklist table is a remote table in a client-server application. See Limiting the Picklist for Views.