Search Results ad_trackable_entities_pk




Overview
Explore in AI Chat

Overview

AD_TRACKABLE_ENTITIES is a core Oracle Applications DBA (AD) repository table owned by the APPLSYS schema. Its documented purpose is to store Oracle Applications entities together with their associated code levels. In practical terms, this table serves as the master registry of the discrete, version-aware objects that the AutoPatch and AD utilities recognize during patching, upgrade, and code-level reconciliation operations. Each row represents one trackable entity, identified by a short abbreviation, and records the baseline and current codelevel against which patches are validated.

Under the heuristic Data Vault classification mined from its foreign key structure, AD_TRACKABLE_ENTITIES is identified as a standalone object. In Data Vault modeling terms this suggests it behaves as an independent hub-like reference set rather than participating in a network of dependent links and satellites. This classification reflects the observation that no foreign key relationships were documented for the table, indicating it is populated and maintained directly by AD utilities rather than through referential dependencies on other transactional tables.

Key Information Stored

The table is documented with seven physical columns in the ETRM 12.2.2 schema definition. The most significant are:

  • ABBREVIATION — The primary key column and the business identifier for each trackable entity. It is the single column forming the AD_TRACKABLE_ENTITIES_PK primary key and also appears in the unique index AD_TRACKABLE_ENTITIES_U1, making it both the surrogate and business-key candidate.
  • NAME — The descriptive, human-readable name of the entity, complementing the terse abbreviation used programmatically.
  • TYPE — Categorizes the entity (for example, by product, schema object, or file class), enabling the AD utilities to group entities during processing.
  • CODELEVEL — The defined code level currently recorded for the entity. This is the central version-control value that AutoPatch and related tools compare against patch prerequisites.
  • BASELINE — The baseline code level, representing the reference level from which subsequent patches and upgrades are measured.
  • USED_FLAG — Indicates whether the entity is currently in use, allowing obsolete or inactive entities to remain registered without participating in active processing.
  • LOAD_FLAG — Signals whether the entity's code level information has been loaded, supporting the lifecycle of entity registration during installation and upgrade.

Because the table is standalone with no documented foreign keys, its integrity is anchored by the two unique structures on ABBREVIATION rather than by parent-child constraints.

Common Use Cases and Queries

The primary consumers of AD_TRACKABLE_ENTITIES are the AD patching utilities — AutoPatch (adpatch), the AD Administration tool, and upgrade driver scripts — which query it to determine whether a prerequisite code level has been applied before a patch proceeds. DBAs and Oracle Support frequently query it during troubleshooting to compare recorded code levels against the file system or against a patch's declared prerequisites.

A typical reporting query lists entities and their current versus baseline code levels:

  • SELECT ABBREVIATION, NAME, TYPE, CODELEVEL, BASELINE, USED_FLAG, LOAD_FLAG FROM APPLSYS.AD_TRACKABLE_ENTITIES WHERE USED_FLAG = 'Y' ORDER BY ABBREVIATION;
  • Filtering by TYPE isolates a class of entity for targeted reconciliation after an upgrade.
  • Comparing CODELEVEL to BASELINE highlights entities whose applied level diverges from their recorded baseline, a common diagnostic during failed or partially applied patches.
  • Joining on ABBREVIATION to an application's own tracking tables allows DBAs to reconcile the central registry with product-specific patch histories.

Related Objects

The ETRM metadata documents no foreign key relationships for AD_TRACKABLE_ENTITIES, reinforcing its standalone classification. Related objects are therefore identified functionally rather than through declared constraints. The most significant include:

  • AD_TRACKABLE_ENTITIES_PK / AD_TRACKABLE_ENTITIES_U1 — the primary key constraint and unique index, both defined on ABBREVIATION.
  • AD_PATCH_DRIVER_FILES / AD_APPLIED_PATCHES — patch history tables whose entries are validated against entity code levels.
  • AD_FILE_VERSIONS — records file-level versions that roll up into the code levels tracked here.
  • FND_PRODUCT_INSTALLATIONS — product installation records that contextualize the entities by application.
  • AD_PATCH_RUN_BUGS — patch run detail used alongside this table during post-patch verification.

Because join keys are not formally declared, DBAs typically relate these objects through the ABBREVIATION and product context rather than enforced foreign keys.