Search Results bne_content_tl_uk1

Overview

BNE.BNE_CONTENTS_TL is the translation table for the content definitions maintained in the Oracle E-Business Suite BNE (Bulk Notification / Application Content) schema. It belongs to the Standard Who and Multi-Language Support (MLS) architecture used throughout EBS 12.1.1 and 12.2.2, and its purpose is to hold the language-specific, human-readable name for every content row defined in the base table BNE_CONTENTS_B. For each content entry stored in the base table, one row exists in this table per installed language; Oracle's Translation Layer (TL) convention confines the translatable text attribute (USER_NAME) to this table while all non-translatable attributes remain in the _B table. The object is owned by the BNE schema, resides in the APPS_TS_TX_DATA tablespace with PCTFREE 10, and carries an ETRM status of VALID. It is a dependent (referenced) object rather than a referencing one: it does not itself reference any other database object, but it is referenced by the APPS synonym BNE_CONTENTS_TL.

From a Data Vault modeling perspective, the heuristic classification of this object is standalone. That classification reflects the absence of foreign-key relationships to other business entities within the dependency graph. Where a Data Vault model is imposed for analytics, however, the natural reading would be that the effective multi-lingual business key (APPLICATION_ID, CONTENT_CODE, LANGUAGE) together with the descriptive USER_NAME attribute constitutes a satellite attached to the content concept defined in the base table, while the base table itself would supply the corresponding hub. This is offered as a modeling suggestion; the documented ETRM relationship data classifies the object as standalone.

Key Information Stored

The table contains eleven documented columns in the 12.2.2 physical schema. The most significant are the following.

• APPLICATION_ID (NUMBER, 15, mandatory) — the application identifier, documented as a foreign key to FND_APPLICATIONS.APPLICATION_ID. Together with the content code and language, it forms the business key.
• CONTENT_CODE (VARCHAR2, 30, mandatory) — the unique code identifying the content entity within the given application; the technical rather than the display identifier.
• LANGUAGE (VARCHAR2, mandatory) — the language into which the content name is translated. This is the driver of the Translation Layer design.
• SOURCE_LANG (VARCHAR2) — the language mirrored by the text. If the text has not yet been translated into the row's LANGUAGE, changes to the source-language row are reflected in this row as well.
• USER_NAME (VARCHAR2, 240) — the actual translatable content: the user-facing name of the content for the given language.
• Standard Who columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN, which provide auditability and support concurrent-program and user tracking via FND_USER and FND_LOGINS.
• ZD_EDITION_NAME — the editioning column introduced with the 12.2 Online Patching architecture; it is only visible in the documented 12.2.2 physical schema and does not appear in the 12.1.1 dictionary view.

The documented primary key is BNE_CONTENTS_TL_PK over (APPLICATION_ID, CONTENT_CODE, LANGUAGE). The unique index that users query most frequently by name, BNE_CONTENT_TL_UK1 (the object referenced in the search term), is a normal, unique index in the APPS_TS_TX_IDX tablespace. In the earlier 12.1.1 dictionary it is defined over (APPLICATION_ID, CONTENT_CODE, LANGUAGE); the 12.2.2 documented schema extends this same unique index to include ZD_EDITION_NAME, allowing the same logical content to coexist across editioning scopes. This index is thus the business-key candidate, not the surrogate PK.

Common Use Cases and Queries

Typical uses center on presenting content names in the logged-in language and on diagnosing translation gaps between the base and translation tables.

• Resolving the display name of a content code for a given session language:

  SELECT application_id, content_code, user_name
  FROM   bne.bne_contents_tl
  WHERE  application_id = :app_id
  AND    content_code  = :code
  AND    language      = userenv('LANG');

• Confirming an untranslated row: comparing SOURCE_LANG with LANGUAGE to detect content that falls back to its source language.
• Finding which translations exist for a content across all installed languages, joined to the base row for the non-translatable attributes.
• Audit reporting using LAST_UPDATE_DATE and LAST_UPDATED_BY to establish when a translated name was last changed and by whom.
• Data-fix validation after running a bulk translation load, verifying that exactly one row exists per (application, content, language) combination against BNE_CONTENTS_B.

A frequently used join pattern is to drive from the base table and outer-join the translation table on the composite key, applying the language predicate in the join clause so that missing translations do not filter out base rows.

Related Objects

The most significant related objects, based on the documented dependency and relationship data, are:

• BNE.BNE_CONTENTS_B — the base table holding content definitions; joined on APPLICATION_ID and CONTENT_CODE.
• APPS.BNE_CONTENTS_TL — the APPS synonym through which the table is referenced, and the object documented as referencing this table.
• FND_APPLICATIONS — source of APPLICATION_ID, providing the application name for reporting.
• FND_USER — referenced by LAST_UPDATED_BY and CREATED_BY to resolve the responsible user.
• FND_LOGINS — referenced by LAST_UPDATE_LOGIN for session-level auditing.
• FND_LANGUAGES — the installable language registry that determines which LANGUAGE codes may appear.
• BNE_CONTENTS_TL_PK and BNE_CONTENT_TL_UK1 — the primary key constraint and the unique business-key index that enforce row uniqueness.