Search Results css_def_defects_tl_pk

Overview

CSS_DEF_DEFECTS_TL is a translation (TL) table belonging to the CSS – Support module in Oracle E-Business Suite. The "_TL" suffix identifies it as a language-specific child table that stores translated, end-user-facing text for a corresponding base entity table, in this case the defect definition records maintained by the Support/Defects schema. In EBS Release 12.1.1 and 12.2.2 the CSS product line is documented as obsolete and not implemented in the current database, so this object is retained only as a legacy schema artifact rather than an active online table. It would hold one row per defect definition per installed language, enabling multilingual presentation of defect descriptions while keeping language-neutral attributes in the base table.

From the relationship data supplied, the object's heuristic Data Vault classification is standalone. As a modeling suggestion, this indicates that no foreign key relationships were mined from the FK structure, so the table is best treated as an independent satellite-style store of descriptive text keyed by language, rather than as a hub or link participating in an explicit integration model.

Key Information Stored

The documented metadata identifies only the primary key columns and does not enumerate the full translation column list. The confirmed columns are:

• DEFECT_ID — the surrogate identifier of the defect definition, inherited from the base table's surrogate primary key and forming the leading column of the composite primary key.
• LANGUAGE — the language code identifying the locale for which the translated defect text is stored; it is the second column of the primary key.

The primary key constraint CSS_DEF_DEFECTS_TL_PK is defined on the column pair (DEFECT_ID, LANGUAGE). This makes DEFECT_ID a business-key candidate inherited from the parent defect definition, while LANGUAGE is the discriminative attribute that makes each defect's translation row unique. In the standard EBS translation-table pattern, the remaining columns carry translated prose fields (for example name and description), but because the metadata does not name them, they should not be assumed; in the obsolete CSS schema these were the descriptive text attributes surfaced to support agents.

Common Use Cases and Queries

Because the table is not implemented in the current database, the primary practical use cases are archival, migration, and impact-analysis activities. Typical scenarios include reconstructing historical defect descriptions for a legacy CSS upgrade, auditing which languages were supported for defect definitions, and confirming schema objects left behind after the module was retired.

A representative query against a legacy environment would join the translation table to its base defect table and filter by language, for example:

• SELECT d.defect_id, t.language, t.name, t.description FROM css_def_defects d, css_def_defects_tl t WHERE d.defect_id = t.defect_id AND t.language = USERENV('LANG');
• Counting available translations per defect: SELECT defect_id, COUNT(*) FROM css_def_defects_tl GROUP BY defect_id HAVING COUNT(*) > 1;
• Verifying installation status before querying: SELECT table_name FROM all_tables WHERE table_name = 'CSS_DEF_DEFECTS_TL';

Reporting use cases center on multilingual defect catalogs and historical support metrics.

Related Objects

The most significant related object is the base defect table that the translation depends on, referenced through the shared DEFECT_ID column. Join patterns follow the EBS convention where the base table supplies language-neutral attributes and the _TL table supplies translated text.

• CSS_DEF_DEFECTS (base table, inferred) — joined on DEFECT_ID; holds the language-independent defect definition.
• CSS_DEF_DEFECTS_TL_PK — the primary key constraint underpinning the (DEFECT_ID, LANGUAGE) uniqueness.
• FND_LANGUAGES — provides the valid LANGUAGE values and installed-language mapping used to filter translated rows.
• FND_TERRITORIES — relates locale and territory context to the LANGUAGE column for reporting.
• CSS defect/incident APIs and concurrent programs (legacy) — historically consumed translated descriptions when displaying defect records to support users.

Because the Data Vault classification is standalone and no foreign keys were mined, joins to these objects are functional rather than enforced by declared constraints, and the table should be treated as non-operational in both 12.1.1 and 12.2.2.