Component Interface Error - Unknown key of uninstantiated object some-record-name.some-field-name (91,16)

A missing List Box Item checkbox on a search record field can silently break the Component Interface Find method, producing an “Unknown key of uninstantiated object” error. This article walks through the root cause, demonstrates the failure on a delivered CI, and provides SQL to audit your environment for the same condition.

The Error

If you have ever invoked the CI Find method and received a message along the lines of:

Unknown key of uninstantiated object {CI_NAME.FIELD_NAME} (91,16)

or seen key fields return <call failed> in the CI Tester Find Results dialog — the cause is a misconfigured search record. Specifically, a search record field that is a Search Key but is missing one critical flag: List Box Item.

How the Find Method Works Internally

In many CI’s you do NOT need to use the find method. If your search record returns unique values or the user of the CI knows all the keys you generally do NOT need to use the find method. There are some components or use cases where you need to use to find method to get the correct item to load or if your search record returns more than one row for the keys which is NOT common but can happen. In those cases, you need to use the find method to get the correct item to load or the CI will not load correctly.

When the Find method executes, PeopleSoft builds its result set by iterating over the FindKeyInfoCollection — the collection of fields exposed as Find keys on the CI. This collection is only populated from search record fields that satisfy two conditions simultaneously:

1. The field is marked as a Search Key (USEEDIT bit 2048 set)
2. The field is marked as a List Box Item (USEEDIT bit 32 set)

A field that is a Search Key but not a List Box Item will not appear in the FindKeyInfoCollection. The Find call will appear to execute — it returns a result row — but any key field in that state comes back as <call failed>. Any subsequent attempt to load or work with that result then throws the uninstantiated object error above.

The CI is broken because of a single unchecked checkbox in App Designer.

Demonstrating It on a Delivered Component: RELATIONSHIP

This is not a theoretical edge case. It can be reproduced exactly against the delivered RELATIONSHIP Component Interface, which is built on the RELATIONSHIPS component using RELATION_SRCH as its search record.

I am using the delivered RELATIONSHIP CI as an example because it is a known issue that exists in the delivered product. This is not a custom component or CI that was built incorrectly. It is a delivered issue that can be found in any environment with Campus Solutions installed, and it is not documented anywhere else. Additionally, you would NOT need to use the Find method on this CI if you were using it for its intended purpose — which is to load a relationship record when you already know the keys. This issue only arises when you try to use Find on the CI, which is a common scenario when the search record returns multiple rows for the same key values or when the consumer of the CI does not know all the keys in advance.

The Search Record

Opening RELATION_SRCH in App Designer reveals the condition immediately. RELATIONSHIP_NBR is field 3 in the record. It is defined as a Search Key — but the List (List Box Item) column is set to No.

This is the exact configuration that breaks the Find method.

The CI Tester Walkthrough

Running the RELATIONSHIP CI through the CI Tester demonstrates the failure in three steps.

Step 1 — Set up the Find. Enter an EMPLID and RELATIONSHIP_NBR value in the Find keys section and click Find.

Step 2 — Find Results return a failed key. The Find Results dialog shows one result row with the correct EMPLID value, but RELATIONSHIP_NBR comes back as <call failed>. The framework could not populate that key because RELATIONSHIP_NBR is not a List Box Item on RELATION_SRCH.

Step 3 — Get Selected fails. Clicking “Get Selected” on that result produces:

Unknown key of uninstantiated object {RELATIONSHIP.RELATIONSHIP_NBR} (91,16)

The Error Message Log confirms the failure from two angles:

003: GetProperty - [CreateKeyInfoCollection].  [Errors Pending]
     This is an invalid property {RELATIONSHIP.RELATIONSHIP_NBR} (91,15)
004: GetProperty - [FindKeyInfoCollection].  [Errors Pending]
     This is an invalid property {RELATIONSHIP.RELATIONSHIP_NBR} (91,15)

Both CreateKeyInfoCollection and FindKeyInfoCollection fail to surface RELATIONSHIP_NBR because it is not a List Box Item. The CI cannot function with Find.

The Fix

The fix is straightforward: restore the affected field as both a Search Key and a List Box Item on the search record. This is a minor record-level customization and does not require changes to the component or CI definition itself.

For RELATION_SRCH:

• Open the record in App Designer
• Locate RELATIONSHIP_NBR
• Ensure both Key and List are checked
• Save and build the record

After that, the CI Find method will correctly populate all key fields in the result set.

Finding Other Affected Records in Your Environment

This condition — a Search Key without a List Box Item flag on a search record that backs a Component Interface — can exist anywhere in your environment, on delivered or custom components. The following SQL identifies all such cases:

-- Search key fields missing List Box Item flag
-- on component search records that have a Component Interface defined
SELECT
    c.PNLGRPNAME   AS component_name,
    c.MARKET,
    c.SEARCHRECNAME AS search_record,
    rf.FIELDNAME,
    rf.FIELDNUM,
    rf.USEEDIT,
    ci.BCNAME       AS component_interface
FROM
    PSPNLGRPDEFN c
    JOIN PSRECFIELD rf ON rf.RECNAME = c.SEARCHRECNAME
    JOIN PSBCDEFN  ci ON ci.BCPGNAME = c.PNLGRPNAME
                      AND ci.MARKET  = c.MARKET
WHERE
    c.SEARCHRECNAME <> ' '
    AND BITAND(rf.USEEDIT, 2048) = 2048  -- Is a Search Key
    AND BITAND(rf.USEEDIT, 32)   = 0     -- List Box Item is NOT checked
ORDER BY
    c.PNLGRPNAME,
    c.MARKET,
    rf.FIELDNUM;

Run this against your environment before you need to use Find on a CI — not after an integration is already failing in production.

What Oracle Should Do When Modifying Search Records

If Oracle — or your own team — needs to change search behavior for a component that already has a CI defined against it, the correct approach is to introduce a new search record and apply it via a Menu Item Override. This pattern lets PIA (online browser) users benefit from the new search behavior while leaving the existing search record — and any CIs built on top of it — completely unaffected.

Modifying a search record field’s List Box Item flag on a component with known CI consumers is a breaking change. The errors it produces don’t point at the real problem, and without knowing where to look you can spend a long time before discovering the cause is a single unchecked checkbox in App Designer.

Key Takeaways

• The CI Find method requires search key fields to also be marked as List Box Items — both flags must be set or the key will not appear in FindKeyInfoCollection
• The delivered RELATIONSHIP CI demonstrates this failure against an unmodified component that ships with PeopleSoft Campus Solutions
• The fix is a minor record-level customization — no component or CI changes required
• Use the SQL above to audit your environment proactively for other affected CIs