Search Results eng_subjects_tl




Overview
Explore in AI Chat

Overview

ENG_SUBJECTS_TL is the translation (Multi-Lingual Support, MLS) table for engineering subjects within the Oracle E-Business Suite Engineering (ENG) module. In EBS, transactional and setup entities that carry user-visible descriptive text are typically split into a base table and a corresponding "_TL" translation table, allowing the same underlying record to present different display values per installed language. ENG_SUBJECTS_TL stores the language-dependent attributes of a subject, principally the subject name, while the language-independent attributes and relationships reside in related base tables. It is owned by the ENG schema and is marked VALID in the documented 12.2.2 physical schema, which lists 10 columns.

From a Data Vault modeling perspective, the heuristic classification derived from the foreign key structure is standalone. This classification is offered as a modeling suggestion only, since the table does not participate in the hub-and-link topology implied by the mined FK graph. As an MLS table keyed by an entity identifier plus language, it behaves more like a descriptive satellite whose grain is the subject-language combination; a Data Vault implementation would typically treat it as a multi-active or language-qualified satellite attached to the subject hub.

Key Information Stored

The column set separates the entity key, the language context, and the audit trail. The most significant columns are:

  • SUBJECT_ID — the identifier of the engineering subject being translated; part of the unique business key and the FK linkage to the subject base data.
  • LANGUAGE — the language code qualifying each translated row; combined with SUBJECT_ID it determines which display value applies to a given session locale.
  • SUBJECT_NAME — the translated, user-visible name of the subject; this is the principal payload column of the table.
  • SOURCE_LANG — the language from which the translation originated, used for MLS translation tracking.
  • ZD_EDITION_NAME — editioning qualifier supporting Online Patching and Edition-Based Redefinition in Release 12.2; it participates in the unique index.
  • CREATION_DATE, CREATED_BY — who created the translation row and when.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard EBS audit columns identifying the most recent modification and its originating login.

The documented unique index ENG_SUBJECTS_TL_U1 spans (SUBJECT_ID, LANGUAGE, ZD_EDITION_NAME). This is the business-key candidate that guarantees one translation per subject per language per edition; SUBJECT_ID alone is not unique because it repeats once for each installed language and edition. The surrogate mechanism relies on this composite uniqueness rather than a single-column primary key.

Common Use Cases and Queries

Typical usage centers on joining translated names back to subject identifiers for locale-appropriate reporting and integration extracts. A common pattern filters to a session or target language and joins to the subject base table to retrieve the display name alongside language-independent attributes:

  • Lov or descriptive-flexfield lookups that must render the subject name in the user's language.
  • Bilingual or multi-lingual reports requiring the subject name per language for a single SUBJECT_ID.
  • Translation completeness audits that detect subjects lacking a row for a given LANGUAGE.
  • Extracts and interfaces that must emit the correct SUBJECT_NAME for a downstream system's locale.

A representative query joins the translation table to the subject base on SUBJECT_ID and constrains LANGUAGE to the desired code, optionally restricting ZD_EDITION_NAME to the active edition in 12.2 environments. When comparing translations, self-joins on SUBJECT_ID across differing LANGUAGE values expose gaps or divergent names.

Related Objects

The documented foreign key links ENG_SUBJECTS_TL.SUBJECT_ID to IGS_UC_COM_EBL_SUBJ, identifying the subject-defining parent entity that this translation table decorates. Although the mined relationship graph is limited and classifies this table as standalone, practical dependencies follow the standard ENG MLS pattern:

  • IGS_UC_COM_EBL_SUBJ — parent subject table; join on SUBJECT_ID.
  • ENG_SUBJECTS (base subject table where present) — supplies language-independent attributes for the same SUBJECT_ID.
  • FND_LANGUAGES — validates and describes the LANGUAGE and SOURCE_LANG values.
  • FND_TERRITORIES / FND_LANGUAGES_TL — supporting lookups for locale resolution in reports.
  • Engineering subject setup and maintenance forms and concurrent programs that read SUBJECT_NAME for display and validation.

Because the table is edition-enabled, joins must respect ZD_EDITION_NAME to avoid mixing translation rows across editions during online patching.