Search Results dpp_log_messages_pk

Overview

DPP_LOG_MESSAGES is a diagnostic logging table owned by the DPP schema (Oracle Price Protection) in Oracle E-Business Suite 12.1.1 and 12.2.2. As its documented description states, the table is used to log debug messages emitted by Price Protection processes. It plays a supporting rather than transactional role in the application: it does not store pricing, agreement, or adjustment data, but instead captures runtime diagnostic output that assists developers and support analysts in tracing program execution, diagnosing failures, and auditing process behavior during concurrent request runs.

The object is registered as VALID in the ETRM metadata, is delivered under the DPP product/module, and is documented with a primary key constraint named DPP_LOG_MESSAGES_PK on the LOG_ID column. The metadata's heuristic Data Vault classification for this object is "standalone," meaning it carries no foreign key relationships to other tables. In Data Vault modeling terms, this suggests treating the object as an independent satellite or reference structure rather than a hub or link, since it neither distributes business keys across the enterprise model nor connects two or more hubs.

Key Information Stored

The documented physical schema in ETRM 12.2.2 is deliberately narrow, listing only two columns:

• LOG_ID — The surrogate primary key of the table, enforced by constraint DPP_LOG_MESSAGES_PK. It also appears as the single column of the unique index DPP_LOG_MESSAGES_U1, making it the documented business-key candidate in the ETRM metadata. In practice, LOG_ID is populated from a sequence and provides the unique handle for each logged message row.
• LOG_MESSAGE — The payload column holding the debug text written by Price Protection code paths. This is the substantive content of the table, capturing the message string generated at each logging point.

Because the ETRM documentation exposes only these two columns, any additional attributes sometimes observed in working systems (for example, timestamp or severity columns) should be confirmed against the actual dictionary definition using DBA_TAB_COLUMNS for the DPP schema before being relied upon in custom code. The authoritative documented structure remains LOG_ID and LOG_MESSAGE.

Common Use Cases and Queries

Typical uses center on troubleshooting Price Protection concurrent programs and debugging custom extensions to Price Protection logic.

• Reviewing the most recent debug output:
  SELECT log_id, log_message FROM dpp.dpp_log_messages ORDER BY log_id DESC;
• Searching for a specific error or pattern within logged text:
  SELECT log_id, log_message FROM dpp.dpp_log_messages WHERE log_message LIKE '%exception%';
• Retrieving a single message by its primary key:
  SELECT log_message FROM dpp.dpp_log_messages WHERE log_id = :p_log_id;
• Housekeeping, since log tables grow quickly in busy environments:
  DELETE FROM dpp.dpp_log_messages WHERE log_id < :p_high_water_mark; followed by a commit and, where appropriate, segment shrink or reorganization.

Because the table is standalone and diagnostic, reporting use is limited; it is most valuable during implementation, upgrade validation between 12.1.1 and 12.2.2, and production incident analysis.

Related Objects

The ETRM metadata records no foreign keys for DPP_LOG_MESSAGES, consistent with its "standalone" classification, so no join columns to parent or child tables are documented. Related objects are therefore functional rather than referential:

• DPP_LOG_MESSAGES_PK — the primary key constraint on LOG_ID.
• DPP_LOG_MESSAGES_U1 — the unique index on LOG_ID, the documented business-key candidate.
• Oracle Price Protection (DPP) concurrent programs and PL/SQL packages — the application code that writes rows into this table at debug logging points.
• FND_LOG_MESSAGES / FND_LOG — the standard EBS logging infrastructure, which serves an analogous diagnostic purpose and may be used alongside or instead of application-specific logging.
• FND_CONCURRENT_REQUESTS — the request log context against which debug output is usually correlated.

Any additional join relationships to Price Protection transactional tables should be verified against the live data dictionary, as none are asserted in the documentation.