Results for “hr_form_data_groups_vl”

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

Overview

HR_FORM_DATA_GROUPS_VL is a translated (VL) view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the PER — Human Resources product family. It presents form data group definitions used by Oracle HRMS forms, resolving the underlying base and translation tables into a single, language-aware result set. The view is the standard read interface for form data groups, which control how a specific form renders and which fields are displayed to the user for a given responsibility or business context.

Because the view applies USERENV('LANG') against the translation table, each session automatically receives only the rows matching its current language setting. This makes the view suitable for concurrent programs, OAF pages, and custom reports that must display user-facing (translated) names rather than the developer-oriented seed data. In the ETRM metadata for 12.1.1 and 12.2.2 the object is listed with status VALID.

Underlying Base Objects

The view is defined over two synonyms that map to base tables in the PER schema:

• HR_FORM_DATA_GROUPS_B — the base (non-translated) table holding the primary key and all language-independent attributes, including APPLICATION_ID, FORM_ID, and DATA_GROUP_NAME.
• HR_FORM_DATA_GROUPS_TL — the translation table holding language-specific columns USER_DATA_GROUP_NAME and DESCRIPTION, keyed by FORM_DATA_GROUP_ID and LANGUAGE.

The join condition is B.FORM_DATA_GROUP_ID = T.FORM_DATA_GROUP_ID AND T.LANGUAGE = USERENV('LANG'), so exactly one translated row is returned per base row for the session language. The view also exposes ROWID from the base table, which allows downstream code to reference the physical base row.

Key Columns

• ROW_ID — ROWID of the corresponding HR_FORM_DATA_GROUPS_B row.
• FORM_DATA_GROUP_ID — Primary key identifying the data group.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the underlying forms/BC4J layer.
• APPLICATION_ID — Identifies the application owning the form.
• FORM_ID — Identifies the specific form to which the data group applies.
• DATA_GROUP_NAME — Internal (untranslated) name of the data group, from the base table. This is the column most commonly matched when a user searches for "data_group_name".
• USER_DATA_GROUP_NAME — User-facing, translated name of the data group.
• DESCRIPTION — Translated description of the data group.
• Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE.

Common Use Cases and Queries

Typical uses include verifying which data groups exist for a given form, troubleshooting form personalization or field display issues, and building custom reports or LOVs that must show translated data group names alongside their internal identifiers.

To list all data groups for a specific form:

• SELECT form_data_group_id, data_group_name, user_data_group_name, description FROM apps.hr_form_data_groups_vl WHERE form_id = :p_form_id ORDER BY user_data_group_name;

To resolve a data group by its internal name as searched by the user:

• SELECT form_data_group_id, application_id, form_id, user_data_group_name FROM apps.hr_form_data_groups_vl WHERE data_group_name = :p_data_group_name;

To search flexibly across both internal and translated names:

• SELECT form_data_group_id, data_group_name, user_data_group_name FROM apps.hr_form_data_groups_vl WHERE UPPER(data_group_name) LIKE UPPER('%'||:p_search||'%') OR UPPER(user_data_group_name) LIKE UPPER('%'||:p_search||'%');

Because the view filters on USERENV('LANG'), queries return only rows for the session's current language. When a translated row does not exist for that language, the join yields no output, which is a frequent cause of "missing" data groups in reports; joining the base table directly, or ensuring the target language is populated in HR_FORM_DATA_GROUPS_TL, resolves such cases.