Search Results css_def_prob_types_tl_pk

Overview

CSS_DEF_PROB_TYPES_TL is the translation table for problem types within the CSS - Support module of Oracle E-Business Suite. The suffix "_TL" identifies this as a translatable (language-specific) table, meaning it stores the user-facing text attributes of a base entity in multiple languages. In this case, the base entity is the problem type defined in the corresponding base table (CSS_DEF_PROB_TYPES_B), and the _TL table carries the language-dependent descriptive columns such as the translated name and description.

The CSS - Support module is designated obsolete in Oracle EBS 12.1.1 and 12.2.2. The documentation explicitly states that this table is not implemented in the database for this instance. Consequently, CSS_DEF_PROB_TYPES_TL should be regarded as a legacy or dormant object: it exists in the data model for historical or upgrade compatibility purposes, but is not populated or actively used in a standard, current deployment. Applications that still reference it are likely tied to pre-existing, non-upgraded, or archival customizations.

The metadata classifies this object by heuristic Data Vault modeling as standalone. Under a Data Vault interpretation, this classification suggests the table behaves as a satellite (or a hub-adjacent descriptive structure) with no FK-derived relationships to other tables in the mined structure. In practical terms, it holds language-dependent descriptive attributes keyed to a parent problem type identifier, making it a straightforward lookup/translation satellite rather than a transactional or linking entity.

Key Information Stored

The table's structure centers on the composite primary key and the translated text payload. The documented columns and their roles are as follows:

• PROBLEM_TYPE_ID — The surrogate/foreign identifier linking the translation row to its base problem type record. This is a business-relevant key candidate that ties the translated content to the logical entity.
• LANGUAGE — The language code identifying the locale of the translated content. This is a business key component, indicating which language the row's text applies to.
• Translated text columns (name/description) — The _TL pattern typically stores the user-facing name and description in the language specified by LANGUAGE. These are the descriptive payload columns that distinguish one language row from another for the same PROBLEM_TYPE_ID.
• Who-columns (created_by, creation_date, last_updated_by, last_update_date) — Standard EBS audit columns recording row creation and modification history; present by convention in translatable tables even when not explicitly enumerated in the excerpt.

The primary key CSS_DEF_PROB_TYPES_TL_PK is a composite of PROBLEM_TYPE_ID and LANGUAGE. In Oracle EBS translatable-table design, PROBLEM_TYPE_ID identifies the parent entity and LANGUAGE identifies the locale, so together they uniquely determine one translated row. The single-column combinations of PROBLEM_TYPE_ID and LANGUAGE are not individually unique; only their pairing is. No separate unique index is documented beyond the composite primary key.

Common Use Cases and Queries

Because the module is obsolete and the table is not implemented, direct production queries are unlikely in a current 12.1.1 or 12.2.2 instance. Where the object is still present (e.g., during migration analysis, data-model documentation, or custom reporting against legacy data), the following patterns apply.

• Retrieving the translated name for a problem type in a given language: join the base and translation tables on PROBLEM_TYPE_ID and filter by LANGUAGE.
• Verifying multilingual coverage: group by PROBLEM_TYPE_ID and count distinct LANGUAGE values to detect missing translations.
• Upgrade and impact assessment: query the data dictionary (ALL_TABLES, ALL_TAB_COLUMNS, ALL_CONSTRAINTS) to determine whether the table exists and whether any custom code references it.
• Reporting: build a language-aware lookup view combining CSS_DEF_PROB_TYPES_B and CSS_DEF_PROB_TYPES_TL for historical problem-type categorization.

A representative join pattern is:

SELECT b.problem_type_id, t.language, t.name
FROM css_def_prob_types_b b, css_def_prob_types_tl t
WHERE b.problem_type_id = t.problem_type_id
AND t.language = USERENV('LANG');

Reports should always constrain LANGUAGE to avoid returning duplicate logical rows across all installed languages.

Related Objects

The most significant related objects follow the standard EBS base/translation pairing and the composite key relationship documented above:

• CSS_DEF_PROB_TYPES_B — The base table holding language-independent problem type attributes; joined to the _TL table on PROBLEM_TYPE_ID.
• CSS_DEF_PROB_TYPES_TL_PK — The primary key constraint spanning (PROBLEM_TYPE_ID, LANGUAGE).
• CSS_DEF_PROB_TYPES_VL — The conventional _VL view that joins base and translation tables to expose the current-language record; likely the primary access path for the entity.
• Other CSS_DEF_*_TL tables — Sibling translation tables in the CSS - Support schema following the same pattern and join semantics.
• FND_LANGUAGES — The EBS language reference that validates the LANGUAGE column values.
• FND_APPLICATION / FND_PRODUCT_INSTALLATIONS — Registration metadata determining whether the obsolete CSS module is installed in a given instance.

Because the heuristic classification is standalone with no FK relationships mined, dependencies are limited to the base table, the _VL view, and language reference tables. Any integration with problem/diagnostic workflows should be validated against the fact that the object is obsolete and undocumented for use.