Search Results fnd_preference




Overview
Explore in AI Chat

Overview

The APPS.FND_PREFERENCE package body implements the internal persistence layer for Oracle E-Business Suite user profile preferences. It provides the runtime logic behind the user-level preference facility that allows individual EBS users, administrators, and application code to store, retrieve, and manipulate named preference values associated with a user account. Preferences govern a wide range of per-user behaviors, including default responsibility, session language, date and number formatting, and numerous application-specific defaults that personalize the user experience across the EBS 12.1.1 and 12.2.2 technology stacks.

In the ETRM classification this object carries an API classification of OTHER and is owned by the APPS schema, with a status of VALID. The package is a foundational dependency rather than a terminal object: according to dependency data, APPS.FND_PREFERENCE is referenced by 29 other packages while itself depending on FND_USER_PKG and the FND_USER_PREFERENCES table. It does not reference any object in the PUBLIC schema beyond the standard facilities it consumes, and it exposes ten documented procedures and functions.

Key Procedures and Functions

The documented interface of FND_PREFERENCE comprises ten entry points, generally arranged as paired public/internal variants:

  • GET — Retrieves the value of a named preference for a specified user, returning the stored setting to the caller.
  • EGET — An error-reporting variant of GET that raises or propagates an exception when the preference cannot be resolved.
  • GETDEFINED — Returns a preference value only when the preference has been explicitly defined, allowing callers to distinguish a defined value from an implicit or default state.
  • PUT — Writes or updates a preference value for a user, creating the entry if it does not already exist.
  • EPUT — An error-reporting variant of PUT that surfaces failures through exceptions.
  • PUTDEFINED — Stores a preference value while marking it as explicitly defined, supporting the semantics exercised by GETDEFINED.
  • EXISTS — Tests whether a given preference has been defined for the user, returning a boolean-style indication.
  • REMOVE — Deletes a single named preference for a user.
  • DELETE_ALL — Removes all preferences associated with a user, typically during account cleanup or reset operations.
  • SAVE_CHANGES — Commits pending preference modifications made through the package's modification routines, controlling transactional boundaries for callers that batch updates.

Tables Accessed

The package persists its data in the FND_USER_PREFERENCES table, accessed through its APPS synonym. This table is the canonical repository for user-level preference name/value pairs in the EBS foundation schema and is the sole documented data store for the package. Read operations implemented by GET, EGET, GETDEFINED, and EXISTS query this table, while PUT, EPUT, PUTDEFINED, REMOVE, and DELETE_ALL perform inserts, updates, and deletes against it. SAVE_CHANGES governs when those modifications are committed.

Supporting dependencies include FND_USER_PKG, which provides user-account context and validation, DBMS_OBFUSCATION_TOOLKIT, which may be used to obscure sensitive preference values, and PLITBLM, the PL/SQL internal table management package. The body also depends on the SYS.STANDARD package for base language constructs.

Usage Notes

FND_PREFERENCE is an internal foundation-layer package. It is invoked indirectly by the forms-based user interface whenever a user changes settings through profile or preferences screens, and by the 29 dependent packages that rely on it as a controlled access mechanism for user preferences. Custom code and concurrent programs that need to read or persist a user preference should call these procedures rather than issuing direct SQL against FND_USER_PREFERENCES, ensuring the defined-versus-default semantics and commit behavior implemented by SAVE_CHANGES are honored. Because the package is not referenced by any database object and depends on the APPS schema, calls should be fully qualified as APPS.FND_PREFERENCE. Administrators performing user maintenance should be aware that DELETE_ALL removes the entire preference set for a user and is not reversible through the package.