Results for “ad_releases”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AD_RELEASES is a core reference table in the APPLSYS schema of Oracle E-Business Suite, owned by the Applications DBA (AD) product. It stores the master list of Oracle Applications releases known to an EBS instance, functioning as the authoritative registry against which patch activity, snapshot operations, and version-aware configuration data are validated. Every release of Oracle Applications registered in the environment — base releases, maintenance packs, and family packs — is represented as a single row identified by a surrogate RELEASE_ID.

In Oracle EBS 12.1.1 and 12.2.2, this table is populated and maintained by AutoPatch and the AD utilities during upgrade, patch application, and Rapid Install operations. Because it anchors release identifiers used across the patching subsystem, it is a long-lived, slowly changing reference object rather than a transactional table. Mined from its foreign key topology, its heuristic Data Vault classification is hub-leaning: it holds a stable business key set with little to no descriptive volatility, making it a natural candidate for modeling as a hub, with dependent release-attribute changes modeled separately as satellites. This is offered as a modeling suggestion, not a documented Oracle design claim.

Key Information Stored

The table contains 14 documented columns. The most significant are:

• RELEASE_ID — surrogate primary key defined by AD_RELEASES_PK, and additionally documented under unique index AD_RELEASES_U1. It is the value propagated into child tables that reference a release.
• MAJOR_VERSION, MINOR_VERSION, TAPE_VERSION — the composite business key captured by unique index AD_RELEASES_U2, expressing the release numbering scheme used by Oracle Applications (for example, the 12.1.1 or 12.2.2 family).
• ARU_RELEASE_NAME — the release name used for ARU (Oracle Applications Release Update) identification, providing a human-recognizable label for the release.
• BASE_RELEASE_FLAG — indicates whether the row denotes a base release rather than a derivative or maintenance release.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective date range during which the release definition is considered active.
• APPROXIMATED_DATES_FLAG — flags whether the associated dates are approximate rather than exact.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY — the standard Oracle Applications auditing columns recording who created and last modified the row and when.
• ROW_SOURCE_COMMENTS — free-form commentary describing the origin of the row, useful when reconciling records introduced by different AD utilities.

The distinction between the surrogate RELEASE_ID and the composite (MAJOR_VERSION, MINOR_VERSION, TAPE_VERSION) business key matters: joins and application logic typically use RELEASE_ID, while deduplication and reconciliation tasks should validate against the composite unique index.

Common Use Cases and Queries

Typical scenarios include identifying the current application release level, auditing which releases have been registered by patching activity, and joining patch-run history to the release that produced it.

SELECT release_id, major_version, minor_version, tape_version,
       aru_release_name, base_release_flag
FROM   applsys.ad_releases
ORDER  BY release_id;

Because AD_PATCH_RUNS carries both RELEASE_ID and UPDATED_TO_RELEASE_ID pointing back to this table, a release-transition report can be built by joining AD_PATCH_RUNS to AD_RELEASES twice — once for the source release and once for the destination release — to show how a patch moved the instance from one release to another. Release-era filtering is another common pattern, restricting queries to rows where START_DATE_ACTIVE and END_DATE_ACTIVE bracket a point in time, or where BASE_RELEASE_FLAG isolates base releases. Reconciliation queries should use the AD_RELEASES_U2 key to detect duplicates or conflicting registrations introduced by successive AutoPatch runs.

Related Objects

The documented foreign key relationships establish AD_RELEASES as a referenced hub. The most significant dependent objects are:

• AD_PATCH_RUNS — references AD_RELEASES twice, via AD_PATCH_RUNS.RELEASE_ID and AD_PATCH_RUNS.UPDATED_TO_RELEASE_ID, recording the release in effect when each patch run executed and the release it advanced to.
• AD_SNAPSHOTS — references AD_RELEASES through AD_SNAPSHOTS.RELEASE_ID, tying each snapshot to the release against which it was captured.
• VEA_VERSIONS — references AD_RELEASES through VEA_VERSIONS.RELEASE_ID, associating version records with a registered release.
• VEA_EXCEPTIONS — references AD_RELEASES through VEA_EXCEPTIONS.RELEASE_ID, linking exception records to the applicable release.

Note that no foreign keys from AD_RELEASES to other tables are documented, confirming its position as a foundational reference object on which the patching, snapshot, and versioning subsystems depend. Its rows are consumed by AD utilities rather than maintained through end-user application forms, so direct DML should be avoided outside of supported AD tooling.