Search Results entry_date

Overview

CS_KB_HISTORIES_VL is a multi-lingual (ML) view owned by the APPS schema in Oracle E-Business Suite, defined within the Customer Support (CS - Service) product family. It presents a translated, language-aware projection of knowledge base history records by joining the base table CS_KB_HISTORIES_B with its translation table CS_KB_HISTORIES_TL. The view carries a status of VALID and is documented for both release 12.1.1 and 12.2.2.

The "_VL" suffix denotes Oracle's standard multilingual view convention: the view exposes language-independent columns from the "_B" table and returns only the translation rows whose LANGUAGE matches the session environment (USERENV('LANG')). This makes the view suitable for end-user reporting, concurrent programs, and integration interfaces where display text must appear in the operator's native language without the developer explicitly handling LANGUAGE predicates. Because it is a view rather than a table, it is read-only with respect to the underlying base objects and inherits their DML and audit characteristics indirectly.

Underlying Base Objects

The documented ETRM metadata lists two referenced base objects, both resolved through synonyms:

• CS_KB_HISTORIES_B — the base (language-independent) table holding the primary history record key and audit columns.
• CS_KB_HISTORIES_TL — the translation table holding language-specific descriptive text.

The view text joins the two tables on HISTORY_ID and restricts the translation side with T.LANGUAGE = USERENV('LANG'). It also projects B.ROWID as ROW_ID, reinforcing the row-level linkage to the base table. The join is an inner join: a history record appears only when a translation row exists for the session language. Where a translation is missing, the base row is not returned by this view, which is an important behavioral consideration for reporting completeness.

Key Columns

• ROW_ID — ROWID of the base table row; useful for identifying the physical base record.
• HISTORY_ID — primary identifier linking base and translation records; the principal join and lookup key.
• HISTORY_NAME — language-independent name of the history entry, sourced from the base table.
• USER_ID — the user associated with the history record.
• ENTRY_DATE — the date the history entry was recorded; this is the column most relevant to the user's search term and is a primary filter for time-based reporting.
• NAME, DESCRIPTION — translated display text from CS_KB_HISTORIES_TL, returned in the session language.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns documenting record provenance and change history.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard EBS descriptive flexfield (DFF) columns, available for customer-specific context and segment data.

Common Use Cases and Queries

The view is typically queried for knowledge base activity reporting, audit trails of article or solution changes, and integrations requiring localized history text. A representative query filtering on the entry date follows:

SELECT h.HISTORY_ID, h.HISTORY_NAME, h.USER_ID, h.ENTRY_DATE, h.NAME, h.DESCRIPTION
FROM APPS.CS_KB_HISTORIES_VL h
WHERE h.ENTRY_DATE >= :p_from_date
AND h.ENTRY_DATE < :p_to_date
ORDER BY h.ENTRY_DATE DESC;

A join to the history identifier for drill-down or per-record audits:

SELECT h.HISTORY_ID, h.ENTRY_DATE, h.NAME
FROM APPS.CS_KB_HISTORIES_VL h
WHERE h.HISTORY_ID = :p_history_id;

Because translated text is filtered by the session language automatically, the same query returns locale-appropriate NAME and DESCRIPTION values without additional LANGUAGE handling. Reports that must return records lacking translations should query the base tables directly rather than this view.