Search Results cs_kb_ele_chg_hists_pk

Overview

The CS_KB_ELE_CHG_HISTS table is a historical junction table within the Oracle E-Business Suite (EBS) Service (CS) module, specifically designed for the Knowledge Base (KB) functionality. Its primary role was to establish and maintain a many-to-many relationship between knowledge base elements (CS_KB_ELEMENTS_B) and their associated change history records (CS_KB_HISTORIES_B). This structure was intended to provide a comprehensive audit trail, linking specific content elements to the various change events or versions they underwent over time. Critically, the official ETRM documentation explicitly states that this table has not been in active use since a version prior to Oracle EBS 11.5.8. Consequently, while the table structure exists in schemas for releases 12.1.1 and 12.2.2, it is a legacy artifact with no active data population or functional purpose in these versions.

Key Information Stored

As a junction table, CS_KB_ELE_CHG_HISTS contains a minimal set of columns whose sole purpose is to define relationships. The table's composite primary key consists of two foreign key columns: ELEMENT_ID and HISTORY_ID. The ELEMENT_ID column references a unique record in the CS_KB_ELEMENTS_B table, which stores the core definitions of knowledge base items such as solutions or articles. The HISTORY_ID column references a unique record in the CS_KB_HISTORIES_B table, which would have stored metadata about a specific change event (e.g., timestamp, user, action type). Together, each row in this table would have represented a single association between one element and one history entry, allowing one element to be linked to multiple histories and vice versa.

Common Use Cases and Queries

Given its deprecated status, there are no standard functional use cases or reporting requirements for this table in Oracle EBS 12.1.1 or 12.2.2. Technical consultants or DBAs might encounter it only during data analysis, schema reviews, or legacy data migration projects. Sample queries would be purely investigative, such as verifying the absence of data or understanding historical data relationships. A typical join pattern to examine any residual data would be:

• SELECT eh.*, ele.element_number, hist.change_date
  FROM cs.cs_kb_ele_chg_hists eh
  LEFT JOIN cs.cs_kb_elements_b ele ON eh.element_id = ele.element_id
  LEFT JOIN cs.cs_kb_histories_b hist ON eh.history_id = hist.history_id;

Any such query is expected to return zero rows in a standard implementation post-11.5.8.

Related Objects

The table's existence is defined entirely by its relationships with two other core Knowledge Base tables, as documented in the ETRM metadata. These are foreign key constraints that enforce referential integrity.

• CS_KB_ELEMENTS_B: This table is referenced via the ELEMENT_ID column. It is the master table for knowledge base element definitions.
• CS_KB_HISTORIES_B: This table is referenced via the HISTORY_ID column. It was designed as the master table for tracking change history metadata.

The primary key constraint CS_KB_ELE_CHG_HISTS_PK on the combination of (ELEMENT_ID, HISTORY_ID) ensures each relationship record is unique. No other standard EBS objects are documented as having dependencies on this deprecated table.