Keys for Accessing Pages

No matter how much time you spend defining and refining your page, your work is useless unless the user can access it. You must add it to a component, and then you must add that component to a menu. When you add a page to a component, you determine what actions the user must perform to access the page and the keys that are required to retrieve rows of information.

The search record that you define for a component determines the key list; that is, search keys for which users are prompted when they select a page and an action. A search record can be either a view that concatenates information stored in several tables or the underlying table itself. Select the search record that contains all of the key items for the primary record underlying the page.

The keys for which the search dialog box prompts should populate the high-level (Level 0 in the page definition) key controls on a page. These key controls always appear before any level-based control on the page and are typically display-only. A search record might differ from a primary record definition, but it must contain all of the Level 0 keys that you placed on the page.

Using Keys for Views

When you create a view that should use key values from a page, each key must be:

• Listed as an output column from the view (not just referenced in the WHERE clause of the view).

• Marked as a key field of the view.

For example, suppose that a page has PERSON.PERSONID as a Level 0 field. PERSONID is the key of the PERSON record. A grid on the page uses the PERSON_ADDRESS_VW view to display addresses for the current person. The SQL statement for the view cannot only mention PERSON.PERSONID in the WHERE clause; PERSONID must be both an output column of the view and a key field of the view.