Results for “bne_content_cols_tl”

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

Overview

BNE_CONTENT_COLS_TL is the translation (language-specific) table for BNE_CONTENT_COLS_B, the base table that defines the content column layout used by Oracle Web Applications Desktop Integrator (BNE/Web ADI). BNE_CONTENT_COLS_B stores the language-independent definition of the columns that make up a desktop integrator "content" definition, while BNE_CONTENT_COLS_TL holds the translated, user-facing text associated with each of those columns for every installed language. It resides in the BNE schema and is marked VALID.

In Oracle EBS 12.1.1 and 12.2.2, this table is one of the standard "_TL" translation pairs that support Multi-Language Support (MLS), allowing a single content definition to present column labels in the session language of each user. The base table owns the structural metadata; the _TL table carries the translatable attributes keyed by LANGUAGE.

From a Data Vault modeling perspective, the metadata classifies this object as standalone (no foreign keys into it were mined). Translating that heuristic into Data Vault terms, BNE_CONTENT_COLS_TL behaves most like a multi-active satellite on the BNE_CONTENT_COLS_B hub, where the driving key set is (APPLICATION_ID, CONTENT_CODE, SEQUENCE_NUM) plus the LANGUAGE discriminator. It carries descriptive, language-dependent attributes rather than relationships, which is consistent with satellite classification.

Key Information Stored

The documented physical schema exposes 12 columns. The most significant are:

• APPLICATION_ID – identifies the owning Oracle application; part of the primary key and of every business key.
• CONTENT_CODE – the content definition identifier; with APPLICATION_ID it scopes the column set defined in BNE_CONTENT_COLS_B.
• SEQUENCE_NUM – the ordinal position of the column within the content definition.
• LANGUAGE – the MLS language code for the translated row.
• SOURCE_LANG – the language of the source text, used in MLS translation workflows.
• USER_NAME – the application user associated with the row.
• ZD_EDITION_NAME – editioning column supporting EBS 12.2 Online Patching (Edition-Based Redefinition).

The remaining audit columns are CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, and LAST_UPDATE_DATE. The primary key is BNE_CONTENT_COLS_TL_PK over (APPLICATION_ID, CONTENT_CODE, SEQUENCE_NUM, LANGUAGE), and the unique index BNE_CONTENT_COLS_TL_UK1 extends this with ZD_EDITION_NAME. Practically, the primary key is the true surrogate/business key, while the UK1 index enforces uniqueness across editions in 12.2.

Common Use Cases and Queries

Typical uses include reporting on defined Web ADI content layouts and auditing which translations exist for a given content definition. A representative query retrieving translated labels for a content definition is:

• SELECT application_id, content_code, sequence_num, language, source_lang FROM bne.bne_content_cols_tl WHERE application_id = :app_id AND content_code = :code AND language = USERENV('LANG') ORDER BY sequence_num;
• Detect missing translations: SELECT b.application_id, b.content_code, b.sequence_num FROM bne.bne_content_cols_b b LEFT JOIN bne.bne_content_cols_tl t ON b.application_id = t.application_id AND b.content_code = t.content_code AND b.sequence_num = t.sequence_num AND t.language = :lang WHERE t.content_code IS NULL;

These patterns are useful during Web ADI layout troubleshooting, MLS completeness checks, and when reconciling content definitions after upgrades or patches.

Related Objects

The following objects are the most significant related dependencies:

• BNE_CONTENT_COLS_B – base table joined on APPLICATION_ID, CONTENT_CODE, SEQUENCE_NUM.
• BNE_CONTENTS_TL / BNE_CONTENTS_B – parent content definitions that own the content code.
• BNE_CONTENT_COLS_TL_PK / BNE_CONTENT_COLS_TL_UK1 – primary key constraint and unique index enforcing row identity.
• FND_LANGUAGES – validates the LANGUAGE value against installed languages.
• FND_APPLICATION – resolves APPLICATION_ID to the owning application.

Because the object is classified as standalone, no inbound referential constraints were mined; consumers typically join through the business-key columns rather than foreign keys.