Search Results obj_code

Overview

APPS.AMV_TEMP_IDS is a global temporary table (GTT) registered in the Oracle E-Business Suite Applications schema. It forms part of the Advanced Matrix Viewer (AMV) subsystem, which supplies the search and filtering infrastructure used by several Oracle EBS application modules. The table is defined in FND Design Data as AMV.AMV_TEMP_IDS and holds a VALID status across both 12.1.1 and 12.2.2 releases, meaning the object is shipped and supported in the standard product installation.

As a global temporary table, AMV_TEMP_IDS is session-isolated: data inserted by one session is invisible to others, and the rows are removed at a transaction boundary, since the documented data duration is SYS$TRANSACTION. This makes the object unsuitable for durable or cross-session storage and positions it strictly as an intermediate scratch area populated and consumed within a single logical operation.

The table is classified as standalone under the heuristic Data Vault model. From a modeling perspective, it therefore does not act as a hub, link, or satellite; it is a transient work table supporting query execution rather than a persistent business entity.

Key Information Stored

The documented physical schema comprises five columns, all owned by APPS. The salient attributes are:

• ID (NUMBER) — The surrogate identifier for each temporary row and the primary key candidate for the table. It distinguishes individual records staged during a search or scoring operation.
• NUMBER_VALUE (NUMBER) — A numeric payload, typically used to hold an entity identifier or measured value associated with the temporary record.
• SCORE (NUMBER) — The ranking or match score assigned to the record, supporting ordered result sets in AMV-driven searches.
• OBJ_CODE (VARCHAR2(30)) — The object code discriminator. This column is the most frequently queried attribute and is the term users search for when investigating this table. It identifies the type or category of the object being scored or matched.
• SECURITY_GROUP_ID (NUMBER) — The security grouping key, carrying a foreign key relationship to FND_SECURITY_GROUPS. It enforces row-level access partitioning consistent with EBS multi-org and function security conventions.

No unique business-key index is documented beyond the ID surrogate, so ID remains the principal reference point for row identification.

Common Use Cases and Queries

Because the table is transaction-scoped, it appears almost exclusively in the execution path of AMV search and scoring routines rather than in reporting. The canonical access pattern retrieves the staged results by object code for a given security group:

• Retrieving scored results: selecting ID, NUMBER_VALUE, SCORE, OBJ_CODE, and SECURITY_GROUP_ID ordered by SCORE to surface the highest-ranked matches.
• Filtering by object type: restricting on OBJ_CODE to isolate results for a specific matrix entity.
• Security validation: joining SECURITY_GROUP_ID to FND_SECURITY_GROUPS to confirm that staged rows respect the caller's authorized security groups.
• Diagnostic tracing: querying the table within a session immediately after invoking an AMV search package to verify that candidate rows were staged correctly.

The documented query text, SELECT ID, NUMBER_VALUE, SCORE, OBJ_CODE, SECURITY_GROUP_ID FROM APPS.AMV_TEMP_IDS, is the standard extraction form. Because of SYS$TRANSACTION duration, any diagnostic query must run inside the same transaction as the populating process; otherwise the rows will have already been purged.

Related Objects

Dependency information places AMV_TEMP_IDS at the intersection of two related objects:

• APPS.AMV_SEARCH_PVT — The AMV search private package is the primary dependent program unit. It references AMV_TEMP_IDS, populating and consuming the temporary rows during scoring operations. This is the principal consumer of the table.
• APPS.FND_SECURITY_GROUPS — Referenced through the SECURITY_GROUP_ID foreign key, this foundation table supplies the security grouping definitions that constrain which rows are visible to a given session.

No other database objects are documented as referencing or being referenced by AMV_TEMP_IDS. Developers tracing AMV behavior should therefore begin with AMV_SEARCH_PVT and follow the security group join into FND_SECURITY_GROUPS to understand the full data flow.