Search Results nls_mode

Overview

FND_LOAD_UTIL is a utility package in the APPS schema that provides helper routines for Oracle Application Object Library (FNDLOAD) configuration migration. FNDLOAD extracts and loads application object definitions to and from flat data files denominated in a documented text format. Its loader logic must decide, for each row in the data file, whether that row should overwrite the corresponding database row. This decision depends on ownership metadata and on the relative last-update timestamps of the file row and the database row. FND_LOAD_UTIL encapsulates that decision logic, together with supporting routines for translating owner identifiers and for NLS handling.

The package resides at the center of the configuration management infrastructure in EBS 12.1.1 and 12.2.2. Whereas the FNDLOAD command-line executable drives file parsing and object-specific loaders, FND_LOAD_UTIL supplies the low-level utility predicates and converters those loaders call. The package is declared AUTHID CURRENT_USER, so it executes with the privileges of the calling session, consistent with its role as a shared utility invoked from many contexts. The documented reference count — utilization by 499 other packages — confirms that it is a foundational dependency rather than an application-facing API.

Key Procedures and Functions

• OWNER_NAME — Returns the owner tag to be written into an FNDLOAD data file. Accepts the user_id value that appears in the LAST_UPDATED_BY column of the row being extracted and converts it to the owner attribute representation used in the file. This makes migrated data portable, since numeric user identifiers are not portable across environments.
• OWNER_ID — Performs the inverse mapping. Given the OWNER attribute value read from an FNDLOAD data file, it returns the user_id to be stored in the WHO columns of the target database row during upload. This resolves owner tags to the identifiers valid in the destination instance.
• UPLOAD_TEST — The central decision routine. It tests whether a database row may safely be overwritten when uploading from an FNDLOAD data file, evaluating the owner attributes of both the database row and the file row together with their last-update timestamps and the CUSTOM_MODE FNDLOAD parameter. It returns TRUE when the overwrite is safe. Because it returns a boolean, it is intended for PL/SQL callers rather than SQL statements.
• NULL_VALUE — Returns the canonical representation used for a null value in the FNDLOAD file format. The routine carries a PRAGMA RESTRICT_REFERENCES declaration asserting WNDS, RNDS, WNPS, and RNPS purity, which permits its use in SQL contexts and guarantees that it neither reads nor writes package or database state.
• SET_NLS_MODE — Sets the package-level NLS_MODE boolean flag, controlling national language support behavior for the utility's operations. The flag is initialized to FALSE.

Tables Accessed

The package references two tables through APPS synonyms. FND_USER is read to resolve user identifiers and owner names in both directions, supporting the OWNER_NAME and OWNER_ID conversions, since owner tags correspond to application user accounts. FND_PRODUCT_GROUPS is accessed to obtain installation and product-group context, which is used to establish NLS and environment settings relevant to load and upload processing. No other tables are documented in the ETRM metadata for this package; the utility is deliberately narrow in scope, operating on caller-supplied parameters rather than maintaining its own persistent state.

Usage Notes

FND_LOAD_UTIL is not invoked directly by end users. It is called by FNDLOAD object handlers and by the 499 dependent packages that implement loader logic for specific product entities, and it may be referenced by custom code that performs programmatic configuration upload. It is not an Oracle Forms or concurrent program entry point; invocation occurs within PL/SQL processing that parses a data file and writes rows. Customizations that replicate FNDLOAD upload behavior should call OWNER_ID and UPLOAD_TEST rather than reimplementing ownership and timestamp comparison, since the documented logic governs CUSTOM_MODE and last-update precedence consistently with standard loader behavior. Because UPLOAD_TEST returns a boolean and the package runs as an invoker-rights utility, calling sessions must have appropriate privileges on the referenced tables and must treat the package as an internal dependency subject to change across patch levels.