Search Results get_used_status




Overview
Explore in AI Chat

Overview

AD_TRACKABLE_ENTITIES_PKG is an internal Oracle E-Business Suite utilities package owned by the APPS schema that manages the metadata registry of trackable entities used by the Oracle Applications database object tracking infrastructure. A trackable entity represents a logical unit of database objects — such as a product, a schema, or a code level — whose code level, baseline, usage state, and load state must be recorded and maintained consistently across a multi-product, multi-patch environment. The package is the programmatic interface to the AD_TRACKABLE_ENTITIES table, providing controlled read and write access to the control attributes that determine whether and how a given entity participates in code-level comparison, patch application, and object loading. It is classified as OTHER rather than as a public API, meaning it is intended primarily for internal use by Oracle Applications maintenance utilities, AD administration programs, and the AutoPatch family of tools, though it can be invoked from custom code within the same architectural assumptions.

Key Procedures and Functions

The documented interface consists of eleven procedures, organized as validators, creators, accessors, and mutators.

  • VALIDATE_NAME — validates that a supplied trackable entity name conforms to the expected identifier rules before it is used elsewhere in the package.
  • VALIDATE_LEVEL — validates that a supplied code level value is acceptable for a trackable entity.
  • CREATE_TE — registers a new trackable entity, accepting a name, description, and type, and returning a status indicator for the operation.
  • GET_CODE_LEVEL — retrieves the current code level and baseline for a named trackable entity, together with a status code.
  • SET_CODE_LEVEL — updates the code level and baseline for a named trackable entity. This is the procedure most directly associated with the "set_code_level" search term: it is the single supported mechanism for advancing or resetting the recorded code level of an entity.
  • GET_USED_STATUS / SET_USED_STATUS — read and write the "used" flag, which indicates whether the entity is actively in use; the getter also returns the entity's code level and baseline.
  • GET_LOAD_STATUS / SET_LOAD_STATUS — read and write the "load" flag, which indicates whether the entity's objects are loaded; the getter likewise returns code level and baseline.
  • GET_TE_INFO / SET_TE_INFO — retrieve and maintain the descriptive attributes of a trackable entity, principally its description and type.

Each procedure returns an x_status OUT parameter following the standard Oracle Applications error-handling convention: a success value when the operation completes, or an error indicator that the caller is expected to check and act upon.

Tables Accessed

The package operates against a single documented table, AD_TRACKABLE_ENTITIES, referenced through an APPS synonym. This table is the repository of record for trackable entity definitions. It stores the entity name, description, and type along with the code level, baseline, used status, and load status attributes. All getter procedures read this table, and all setter procedures, together with CREATE_TE, write to it. Because there is a one-to-one correspondence between the procedures and the columns of this table, the package effectively encapsulates all direct SQL access to AD_TRACKABLE_ENTITIES.

Usage Notes

AD_TRACKABLE_ENTITIES_PKG is normally invoked by Oracle Applications maintenance and patching infrastructure rather than by end users. In Oracle EBS 12.1.1 and 12.2.2 it is used during AD administration operations, AutoPatch processing, and code-level management activities, where the recorded code level of an entity must be synchronized with the actual state of the database. The SET_CODE_LEVEL procedure is the typical entry point when an administrator or tool needs to move an entity to a new code level, override a baseline, or correct a stale value after a failed patch cycle. Callers must always inspect the returned x_status value, as the package signals both validation failures and SQL errors through that parameter rather than by raising exceptions. Because the package is classified as OTHER and is referenced by only one other package, customizations that call it directly should be treated as internal integrations: they must run as the APPS user, must respect the underlying table's integrity constraints, and should be reviewed before upgrades, since the interface is not guaranteed to remain stable across releases.