Results for “data_type_code”

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

Overview

The view APPS.EGO_FP_DATA_TYPES_V is a reporting and integration object within the EGO – Advanced Product Catalog product of Oracle E-Business Suite, valid in releases 12.1.1 and 12.2.2. Its documented purpose is to expose the set of function parameter data types available to EGO function definitions. In the Advanced Product Catalog data model, functions represent configurable behaviors whose parameters are strongly typed. Rather than presenting these types as raw lookup identifiers, the view resolves them into displayable meanings by joining function metadata to the lookup values maintained by the Oracle Application Object Library.

Because it is a view and not a base table, it is read-only and carries no transactional weight. Its role is to provide a stable, denormalized projection of parameter type information that can be consumed by reports, concurrent programs, OAF pages, and external integrations without requiring the consumer to understand the internal lookup encoding used by the EGO module.

Underlying Base Objects

The view text defines it over two referenced objects, both surfaced as synonyms in the APPS schema:

• EGO_FUNCTIONS_B – the base table storing EGO function definitions, including the function identifier and the function type code used to segment parameter data types.
• FND_LOOKUP_VALUES – the Oracle Application Object Library lookup values table, restricted here to lookup types beginning with EGO_EF_FUNC_PARAM_DATA_TYPE.

The join condition links lookup values to functions in two ways. First, the character at position 29 of the lookup type string is compared against the function type held on the function record, so that only data types belonging to the appropriate function category are returned. Second, the view restricts rows to VIEW_APPLICATION_ID = 0 and LANGUAGE = USERENV('LANG'), ensuring that translations are returned for the session language and that only the shared view-level application context is honoured. The relationship is therefore many-to-one from data types to functions: a single function may be associated with multiple eligible parameter data types.

Key Columns

• FUNCTION_ID – Surrogate identifier of the EGO function, sourced from EGO_FUNCTIONS_B.FUNCTION_ID. This is the join key back to the function definition and to other function-related views.
• DATA_TYPE_CODE – The lookup code from FND_LOOKUP_VALUES representing the parameter data type. This is the value passed programmatically when a parameter's type must be specified.
• DATA_TYPE_MEANING – The translatable, user-facing meaning corresponding to the data type code, suitable for display in list of values controls and reports.

The three-column projection is deliberately minimal, so the view is typically joined to EGO_FUNCTIONS_B or related function metadata to obtain names and descriptions.

Common Use Cases and Queries

Typical scenarios include validating the data types permitted for a given function, populating LOVs for parameter type selection, and auditing which codes exist across function types. The column DATA_TYPE_CODE is frequently the search term because consumers need the enumerated codes rather than the display text.

A representative query retrieves all data types for a specific function:

• SELECT v.data_type_code, v.data_type_meaning FROM apps.ego_fp_data_types_v v WHERE v.function_id = :p_function_id ORDER BY v.data_type_meaning;

To enumerate distinct codes across the catalog:

• SELECT DISTINCT data_type_code, data_type_meaning FROM apps.ego_fp_data_types_v ORDER BY data_type_code;

Because the view depends on session language, clients should set the correct NLS environment before querying to obtain the desired translated meanings.