Search Results ahm_odf_tab_columns_h




Overview
Explore in AI Chat

Overview

AHM_ODF_TAB_COLUMNS_H is a history (audit) table belonging to the AHM — Hosting Manager product within Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to store historical column information that was parsed from ADPATCH, the Oracle Applications patching driver, for subsequent creation or reconstruction of object definitions. It therefore acts as a staging and audit artifact rather than a transactional or user-facing table.

The AHM module is flagged as obsolete in the ETRM metadata, and the object carries the explicit notation “Not implemented in this database.” This means the table may not exist in a given EBS environment and should never be assumed present. Where it does exist, it is populated by internal patch-analysis and Hosting Manager routines rather than by application screens or concurrent requests. Because the recorded columns describe parsed DDL fragments (table columns, identifiers, and the patch from which each was derived) rather than master data, the table functions as a historical record of metadata extraction events.

The heuristic Data Vault classification mined from its foreign-key structure is standalone. In Data Vault modeling terms this suggests treating AHM_ODF_TAB_COLUMNS_H as neither a hub, link, nor satellite in the strict sense, but as an independent, self-contained historical snapshot keyed by a composite of its own attributes. A modeler would typically retain it as an isolated history store or treat it as a source for a patch/column effectivity satellite if integrated into a broader warehouse design.

Key Information Stored

The table is defined with a composite primary key, AOTCH_PK, comprising three columns: COLUMN_ID, TABLE_ID, and PATCH_ID. Together these form the surrogate primary key that uniquely identifies each historical column record. No separate unique indexes or alternate business keys are documented in the available metadata; consequently COLUMN_ID, TABLE_ID, and PATCH_ID simultaneously serve as the primary key and the only documented uniqueness constraint.

  • COLUMN_ID — Identifier of the parsed column; part of the composite primary key. Distinguishes individual column definitions within a table.
  • TABLE_ID — Identifier of the table to which the parsed column belongs; part of the composite primary key.
  • PATCH_ID — Identifier of the ADPATCH patch from which the column definition was parsed; part of the composite primary key and the dimension that makes the record “historical.”

The metadata excerpt does not enumerate additional descriptive attributes such as column name, data type, or nullability. Readers requiring those details must inspect the live data dictionary (USER_TAB_COLUMNS, ALL_CONS_COLUMNS) in an environment where the table is actually implemented, since the ETRM documentation limits the documented column set to the three key attributes.

Common Use Cases and Queries

Because the table is obsolete and often unimplemented, practical usage is confined to archaeology, upgrade analysis, and patch-impact investigation. Typical queries confirm existence, trace which patch introduced a column, or reconstruct column-level history across patch levels.

  • Existence check: SELECT COUNT(*) FROM all_tables WHERE table_name = 'AHM_ODF_TAB_COLUMNS_H'; to determine whether the object is present before writing dependent code.
  • Patch-level column history: SELECT patch_id, table_id, column_id FROM ahm_odf_tab_columns_h ORDER BY patch_id, table_id, column_id;
  • Columns for a given table: filter on TABLE_ID to list every parsed column associated with one object across patches.
  • Patch comparison: self-join on TABLE_ID and COLUMN_ID across differing PATCH_ID values to detect additions or removals.

Reporting use cases center on patch-audit reports and upgrade readiness assessments rather than operational reporting.

Related Objects

The metadata classifies the object as standalone, and no foreign-key targets or dependents are documented. The most significant conceptual relationships are therefore to the following, joined on the columns noted:

Absent documented foreign keys, these relationships should be treated as logical joins on patch and table identifiers rather than enforced constraints.