Results for “bne_menus_tl_uk1”

9 results




Overview
Explore in AI Chat

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

Overview

BNE.BNE_MENUS_TL is the translation (TL) table for the BNE_MENUS entity in Oracle E-Business Suite. It stores the language-specific, translated names of the viewers defined in the base table BNE_MENUS_B. As a translation table, it follows the standard Oracle EBS multilingual pattern: one row exists for each viewer for each installed language, so that the same viewer can present a localized user name to users in different locales.

The column USER_NAME holds the displayed text for the viewer, while SOURCE_LANG identifies the language the text mirrors until an explicit translation is supplied. From a Data Vault modeling perspective, the supplied metadata classifies this object as standalone (it references no other database object through foreign keys). Following that heuristic, BNE_MENUS_TL is best understood not as a hub or link, but as a language-qualified descriptive satellite of the BNE_MENUS_B business entity, keyed by the combination of APPLICATION_ID, MENU_CODE, and LANGUAGE. The row's descriptive payload (USER_NAME, SOURCE_LANG) is dependent on that composite key, which is characteristic of a satellite rather than an independent hub.

Key Information Stored

The table carries eleven documented columns. The most significant for identification and business use are:

  • APPLICATION_ID — the application identifier, a foreign key to FND_APPLICATIONS.APPLICATION_ID, scoping the viewer to a specific EBS application.
  • MENU_CODE — the unique code identifying the entity for the given APPLICATION_ID; a VARCHAR2(30) business identifier.
  • LANGUAGE — the language of the stored translation; combined with the two columns above it forms the translation key.
  • USER_NAME — the translated user name of the viewer (VARCHAR2(240)); this is the human-readable output of the row.
  • SOURCE_LANG — the language the text mirrors; if no translation exists for LANGUAGE, changes to the source-language row are reflected here.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE — the standard Who columns recording row audit history.
  • ZD_EDITION_NAME — the editioning column that participates in the unique business-key index and supports Oracle EBS online patching (edition-based redefinition).

The surrogate-style primary key is BNE_MENUS_TL_PK (APPLICATION_ID, MENU_CODE, LANGUAGE). The documented unique index BNE_MENUS_TL_UK1 covers APPLICATION_ID, MENU_CODE, LANGUAGE, and ZD_EDITION_NAME; because it includes the editioning column, BNE_MENUS_TL_UK1 — the object the user searched for — is the true business-key candidate index and is most commonly encountered in execution plans and index-usage reports on this table.

Common Use Cases and Queries

Typical scenarios include retrieving a localized viewer name for a given application and menu code, auditing translation coverage across languages, and joining the translation back to the base table. A basic retrieval pattern is:

  • SELECT USER_NAME FROM BNE.BNE_MENUS_TL WHERE APPLICATION_ID = :app_id AND MENU_CODE = :code AND LANGUAGE = USERENV('LANG');
  • Filter on the business-key columns that satisfy BNE_MENUS_TL_UK1 to ensure an index-driven single-row lookup.
  • Join to BNE_MENUS_B on APPLICATION_ID and MENU_CODE to compare base and translated names.
  • Query rows where SOURCE_LANG = LANGUAGE to identify records still displaying untranslated source text.

Related Objects

The most significant related objects are:

  • BNE_MENUS_B — the base table holding the untranslated viewer definitions; joined on APPLICATION_ID and MENU_CODE.
  • FND_APPLICATIONS — source of the APPLICATION_ID foreign key; joined on APPLICATION_ID.
  • FND_USER — referenced by CREATED_BY and LAST_UPDATED_BY; joined on USER_ID.
  • FND_LOGINS — referenced by LAST_UPDATE_LOGIN; joined on LOGIN_ID.
  • APPS.BNE_MENUS_TL — the APPS-layer synonym used in application SQL.

Because the metadata records no outbound foreign keys from BNE_MENUS_TL itself, the contextual relationships above arise from the documented column semantics and standard EBS conventions rather than from enforced constraints on this table.