Search Results get_values

Overview

FND_CACHE_VERSIONS_PKG is an Oracle E-Business Suite database package owned by the APPS schema that manages the FND_CACHE_VERSIONS table, a lightweight repository used to track named cache entries and their current version numbers. In EBS 12.1.1 and 12.2.2, the package is classified under the generic API category OTHER within the ETRM repository. Its primary purpose is to provide a centralized mechanism for versioning application-level caches so that dependent sessions can detect when a cached value has been invalidated or refreshed. The package body, last modified in 2006 per the header comment (AFCCHVRB.pls, version 120.4), relies on PL/SQL bulk-collect constructs to load the entire FND_CACHE_VERSIONS table into package-level associative arrays, offering fast in-memory lookups of version numbers without repeatedly querying the database.

Key Procedures and Functions

The package exposes five documented program units. The GET_VALUES procedure performs a bulk collect against FND_CACHE_VERSIONS, populating the package-global arrays cacheName and cacheVersion with every NAME/VERSION pair in the table. It is the internal refresh routine invoked after any mutation, ensuring subsequent lookups see current data. The ADD_CACHE_NAME procedure accepts a cache name and inserts a new row into FND_CACHE_VERSIONS with an initial version value of zero, then calls GET_VALUES to refresh the arrays.

The BUMP_VERSION procedure increments the VERSION column by one for a given cache name. If the UPDATE affects zero rows (the name does not exist), it delegates to ADD_CACHE_NAME; otherwise it refreshes the arrays via GET_VALUES. The GET_VERSION function returns the current version number for a supplied cache name, initializing a local return value of -1 and refreshing the arrays when they are null. Per the source comment tied to Bug 5629463, the routine is designed never to raise an exception, returning -1 when the requested name is absent so callers can treat that value as an authoritative "not found" signal. The CHECK_VERSION function completes the documented set, providing a comparison capability typically used by calling code to validate whether a held version is still current.

Tables Accessed

The package operates directly on the FND_CACHE_VERSIONS table via APPS synonyms. This table holds the NAME and VERSION columns that constitute the cache registry. All five program units read from it, while ADD_CACHE_NAME and BUMP_VERSION perform inserts and updates respectively. The documented reference to PLITBLM reflects the standard PL/SQL internal table machinery underlying the bulk-collect operations. No other application tables are touched, which keeps the package narrow in scope and low-risk to modify.

Usage Notes

Because the package is referenced by zero other packages in the documented metadata, it is invoked primarily from client-side code, forms, or custom PL/SQL rather than from a server-side dependency chain. Typical usage patterns include a custom form or concurrent program registering a cache name with ADD_CACHE_NAME, calling BUMP_VERSION whenever the underlying cached data changes, and then calling GET_VERSION or CHECK_VERSION to decide whether to rebuild a cached value. Developers working with the user's search term "get_values" should note that this procedure is a low-level refresh utility: it is not normally called directly by external code, but understanding its role clarifies why version lookups remain consistent after ADD_CACHE_NAME or BUMP_VERSION execute. Since GET_VERSION never raises exceptions and returns -1 for unknown names, custom code should test for that sentinel before relying on a version value.