Search Results is_patch_applied

Overview

AD_PATCH is an Oracle Applications internal PL/SQL package owned by the APPS schema and shipped in support of the Oracle E-Business Suite patching and maintenance infrastructure. Its principal business function is to provide programmatic answers to questions about patch state across an EBS environment: whether a given patch has been applied, whether a specific code line or file has been copied into an application tier, whether a bug fix has been registered, and what status a patch run currently holds.

The AD_PATCH package is a foundational dependency of the AD (Applications DBA) product family. It is referenced directly by AD_FEATURE_VERS_PKG, by the FND_UMS_ANALYSIS_ENGINE, and by itself through recursion, confirming its role as a shared service layer for patch verification rather than as a user-facing API. Because it sits beneath the AD utilities, it is exercised during patching, upgrade, rapid clone, and patch validation workflows, where the AD tooling and the Oracle Universal Installer / Online Patching stack must reconcile recorded patch metadata with the physical state of the file system and database.

Key Procedures and Functions

Ten documented procedures and functions constitute the public surface of AD_PATCH:

• IS_PATCH_APPLIED — Determines whether a specific patch has been applied in the current environment, using the patch run and bug tracking data to establish the result.
• IS_CODELINE_PATCH_APPLIED — Extends the patch check to an individual code line, allowing callers to verify that a particular file version has been delivered by a patch.
• IS_FILE_COPIED — Reports whether a named file has been copied to the application tier, supporting reconciliation of the file system against patch records.
• MARK_PATCH_SUCC — Records the successful completion of a patch, updating the corresponding patch run and bug status rows.
• MARK_BUG_SUCC — Records the successful application of an individual bug fix within a patch run.
• SET_PATCH_STATUS — Sets or transitions the status value associated with a patch run.
• GETAPPLTOPID — Resolves the APPL_TOP identifier for the current or specified application tier, a prerequisite for nearly every patch-state lookup.
• COMPARE_VERSIONS — Compares two version strings, providing the ordering logic used to determine whether a delivered file version supersedes the installed one.

Two additional documented routines round out the interface, covering ancillary patch-state bookkeeping. No parameter lists are published in the ETRM metadata; callers should treat these signatures as internal and subject to change between maintenance packs.

Tables Accessed

AD_PATCH reads and writes the core AD patch repository. Patch run history is held in AD_PATCH_RUNS, with per-bug detail in AD_PATCH_RUN_BUGS and the actions taken on each bug in AD_PATCH_RUN_BUG_ACTIONS. Patch and bug definitions themselves come from AD_BUGS, AD_BUGS_S (the translated snapshot), and the associated views. File-level verification uses AD_FILES and AD_FILE_VERSIONS, while AD_APPL_TOPS supplies the application tier identifiers resolved by GETAPPLTOPID.

Snapshot reconciliation relies on AD_SNAPSHOTS, AD_SNAPSHOT_BUGFIXES, AD_SNAPSHOT_BUGFIXES_S, and AD_SNAPSHOT_FILES, which together describe the recorded baseline of applied fixes and delivered files. AD_TRACKABLE_ENTITIES and FND_PRODUCT_GROUPS provide environment context. DUAL is used for scalar evaluations. Writes are concentrated in the patch run and snapshot table families; reads dominate the definition tables.

Usage Notes

AD_PATCH is an internal support package and is not intended for direct invocation from Oracle Forms or from end-user concurrent programs. It is consumed by AD utilities, the Oracle Universal Installer, and by other AD/FND packages such as AD_FEATURE_VERS_PKG and FND_UMS_ANALYSIS_ENGINE. Custom code should generally query the supported AD views rather than call these routines, since the package contract may change across 12.1.1, 12.2.2, and later AD patch levels.

Where custom validation is unavoidable, callers should invoke AD_PATCH only within the same maintenance window and privileges context as the AD utilities, and should anticipate that Online Patching in 12.2.2 introduces editioning considerations that affect how patch-state results are interpreted. Because the package maintains state as well as reads it, the MARK_PATCH_SUCC, MARK_BUG_SUCC, and SET_PATCH_STATUS routines must not be called outside of a controlled patching session.