Results for “fnd_perf_event_lookup”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_PERF_EVENT_LOOKUP is a reference table owned by the APPLSYS schema within the FND – Application Object Library product of Oracle E-Business Suite. It is documented as VALID in ETRM for release 12.2.2 and carries the annotation "- Retrofitted," indicating that the object was catalogued into the reference model rather than authored as a new feature of that release. The table functions as a lookup or enumeration repository, mapping short internal codes to descriptive full names. Objects of this class typically hold a fixed population of rows that other components of the application reference instead of hard-coding literal values, which supports consistent labeling in diagnostics and user interfaces.

The retrofitted designation, combined with the absence of any documented foreign key relationships, suggests the table is an independent code list rather than a transactional detail store. Under the heuristic Data Vault classification provided in the metadata, FND_PERF_EVENT_LOOKUP is modelled as standalone. In practical terms this is a reference or lookup construct that behaves like a small, self-contained hub of codes; it is not a link table joining two entities, nor is it a satellite carrying descriptive history. When reverse-engineering or documenting this object, it should be treated as an independent reference set.

Key Information Stored

The documented physical schema for release 12.2.2 comprises seven columns, several of which are standard EBS audit and session attributes rather than business data.

• CODE – The single documented column in the primary key FND_PERF_EVENT_LOOKUP_PK. This is the unique identifier for each lookup row, and in this family of tables the primary key column also serves as the business key from the perspective of consumers.
• FULL_NAME – The descriptive label associated with the code, providing the human-readable or expanded form of the identifier for display and reporting.
• CREATION_DATE – Audit column recording when the row was inserted.
• CREATED_BY – Audit column identifying the user who created the row.
• LAST_UPDATE_DATE – Audit column recording the most recent modification.
• LAST_UPDATED_BY – Audit column identifying the user responsible for the most recent modification.
• LAST_UPDATE_LOGIN – Audit column capturing the login session associated with the last update.

Only CODE is documented as a primary key element; no separate unique index beyond the primary key is listed. Because the primary key is a meaningful code rather than a generated surrogate number, business-key and primary-key roles coincide in this object. The six audit columns follow the standard WHO-column convention used throughout APPLSYS and should not be treated as business attributes.

Common Use Cases and Queries

The principal use of FND_PERF_EVENT_LOOKUP is decoding codes into descriptive names for inclusion in reports, extracts, and diagnostic output. A straightforward projection returning the code and its full name is the most common access pattern:

• SELECT code, full_name FROM applsys.fnd_perf_event_lookup; — used to populate pick lists, LOV queries, or reference data extracts.
• SELECT full_name FROM applsys.fnd_perf_event_lookup WHERE code = :code; — single-row lookup by the primary key for on-screen display.
• SELECT l.code, l.full_name FROM applsys.fnd_perf_event_lookup l ORDER BY l.full_name; — ordered presentation of the reference set.
• Joins from a fact or detail table to FND_PERF_EVENT_LOOKUP on the code column to replace stored codes with readable text in reporting queries.

Because the table is small and static, it is commonly queried without restriction and cached by reporting layers. Audit columns can be selected to confirm when the reference set was last maintained, which is useful during reconciliation of publication snapshots.

Related Objects

The ETRM relationship data classifies this object as standalone, and no foreign key constraints are documented. Consequently, related objects must be identified by convention rather than by declared referential integrity:

• FND_PERF_EVENT_LOOKUP_PK – the primary key constraint defined on the CODE column, the authoritative access path for the table.
• Other FND_PERF_* objects – sibling performance and event structures that share the same lookup-code convention and are typically joined on the code value.
• APPLSYS WHO-column consumers – standard EBS audit views and diagnostics that interpret CREATED_BY, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.
• FND_LOOKUP_VALUES / FND_LOOKUPS – the general FND lookup framework, which provides the conceptual analogue for code-to-name translation even though no FK relationship is documented here.

Any join to a dependent table should be built on the CODE column, as it is the only documented key attribute. Analysts should verify referential usage in the target environment before assuming enforcement, since the relationship data records this object as standalone.