Search Results context_column_name




Overview

FND_DESCRIPTIVE_FLEXS_VL is a seeded, read-only view in the APPS schema belonging to the FND – Application Object Library product. It presents the definition header of every descriptive flexfield registered in the Oracle E-Business Suite instance, combining the language-independent definition attributes with the language-specific translated text. The "_VL" suffix denotes a validated, translated view: it exposes the base definition columns plus the TITLE, FORM_CONTEXT_PROMPT, and DESCRIPTION values appropriate to the session language, resolved through USERENV('LANG').

Because a descriptive flexfield is the primary mechanism by which customers extend standard EBS tables without modifying seeded schema objects, this view is the canonical reporting source for questions about what flexfields exist, which tables and columns they are attached to, and how their context (global) segments behave. It surfaces one row for the currently installed language only, so multilingual reporting automatically returns the user's own prompt and title text. Applications code, diagnostics scripts, and custom integrations query it rather than reading FND_DESCRIPTIVE_FLEXS directly, since it removes the need to join the translation table manually.

Underlying Base Objects

The view is defined over two base objects, both referenced through APPS synonyms. FND_DESCRIPTIVE_FLEXS supplies the definition-level columns, aliased as B in the view text. FND_DESCRIPTIVE_FLEXS_TL supplies the translated columns — TITLE, FORM_CONTEXT_PROMPT, and DESCRIPTION — aliased as T. The join is a one-to-one equijoin on APPLICATION_ID and DESCRIPTIVE_FLEXFIELD_NAME, with an additional filter restricting rows to the session language.

FND_DESCRIPTIVE_FLEXS is the single-row-per-flexfield definition table that also stores the frozen state, protection status, and context handling rules. FND_DESCRIPTIVE_FLEXS_TL holds the same flexfield identity translated into each installed language. Because both are synonyms pointing to the FND schema, the view behaves as a standard editioning-compatible object and returns only flexfields visible to the current application context.

Key Columns

Common Use Cases and Queries

A frequent requirement is locating all flexfields whose definition has been frozen, to audit change control or to confirm that a structure is locked before an upgrade:

SELECT application_id,
       descriptive_flexfield_name,
       application_table_name,
       context_column_name,
       freeze_flex_definition_flag
  FROM apps.fnd_descriptive_flexs_vl
 WHERE freeze_flex_definition_flag = 'Y'
 ORDER BY descriptive_flexfield_name;

To find every flexfield defined against a specific table, and to confirm the terminology context behavior:

SELECT descriptive_flexfield_name,
       title,
       form_context_prompt,
       context_required_flag,
       protected_flag
  FROM apps.fnd_descriptive_flexs_vl
 WHERE application_table_name = 'PO_HEADERS_ALL'
   AND freeze_flex_definition_flag = 'N';

Integration and migration routines use the view to enumerate flexfields for a given application before generating DFF import metadata:

SELECT descriptive_flexfield_name, concatenated_segs_view_name,
       concatenated_segment_delimiter
  FROM apps.fnd_descriptive_flexs_vl
 WHERE application_id = 20010;

Because the view already resolves translated text and the freeze state, it is the preferred source for DFF inventory reports, upgrade readiness checks, and any custom concurrent program that must reason about whether a descriptive flexfield can still be redefined.