Search Results owner_req_id




Overview
Explore in AI Chat

Overview

FND_CONC_STATE_LOOKUPS_VL is a seeded, read-only view owned by the APPS schema in Oracle E-Business Suite. It belongs to the FND — Application Object Library product and is documented with the notation "Retrofitted," indicating that it is a compatibility construct introduced or reconciled to preserve backward compatibility across EBS releases, including 12.1.1 and 12.2.2. The view exposes the concurrent program state lookup definitions used by the Concurrent Manager subsystem, pairing the language-independent lookup rows with their translated meaning and description text based on the session language.

Conceptually, the "_VL" suffix identifies this as a "view with language" — a join that returns a single localized row per lookup value for the current runtime language. It therefore serves as the primary reporting and integration surface for concurrent request states (such as Pending, Running, Completed, Error, and Inactive), allowing callers to resolve internal state codes into user-facing text without directly navigating the translation tables.

Underlying Base Objects

The view is defined over two referenced base objects, both exposed as synonyms in the APPS schema:

  • FND_CONC_STATE_LOOKUPS — the language-independent base table holding the lookup rows, their type identifier, lookup value, enabled flag, active date range, audit columns, and the OWNER_REQ_ID column.
  • FND_CONC_STATE_LOOKUPS_TL — the translation table supplying the MEANING and DESCRIPTION attributes per installed language.

The join condition requires that LOOKUP_TYPE_ID and LOOKUP_VALUE match between the two tables, and that the translation row's LANGUAGE column equals USERENV('LANG'). This construction means the view returns exactly one row per lookup value, rendered in the language of the invoking session. Because the view is defined against the translation table rather than a single flat source, rows are implicitly filtered to the current language, and no explicit language predicate is required from the query author.

Key Columns

  • ROW_ID — the ROWID of the underlying base table row, usable for direct row addressing.
  • LOOKUP_TYPE_ID — numeric identifier of the lookup type to which the value belongs, and one half of the join key.
  • LOOKUP_VALUE — the internal, language-independent code for the concurrent state; the second half of the join key.
  • MEANING and DESCRIPTION — the translated, user-facing label and longer explanation, sourced from the translation table and returned in session language.
  • ENABLED_FLAG — indicates whether the lookup value is currently active for use.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — the effective date window during which the lookup value is considered valid.
  • OWNER_REQ_ID — the request identifier historically associated with ownership of the lookup row, frequently cited in concurrent processing diagnostics.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — standard WHO audit columns.

Common Use Cases and Queries

The view is commonly queried to join concurrent request data (for example FND_CONCURRENT_REQUESTS.PHASE_CODE and STATUS_CODE) to their translated display text, to build lookup-driven LOVs and reports, and to audit which state values remain enabled. Because OWNER_REQ_ID is exposed here, it is also referenced when investigating the provenance of a state code.

A typical query retrieving only active, current-language state definitions:

  • SELECT lookup_value, meaning, description, enabled_flag, owner_req_id FROM apps.fnd_conc_state_lookups_vl WHERE enabled_flag = 'Y' ORDER BY meaning;

And a join to concurrent requests to display readable request status text:

  • SELECT r.request_id, r.phase_code, r.status_code, v.meaning FROM apps.fnd_concurrent_requests r, apps.fnd_conc_state_lookups_vl v WHERE v.lookup_value = r.status_code;

Because the view enforces the session-language predicate, no additional LANGUAGE filter is required; results are automatically localized. Authors should note that invalid or disabled lookups are still returned unless ENABLED_FLAG is explicitly constrained, and that date-range validity is not enforced by the view itself.