Search Results stored_date_format

Overview

APPS.FND_FLEX_SERVER1 is an internal Oracle E-Business Suite package body that provides the server-side engine for Oracle Flexfields. It belongs to the Applications DBA (FND) schema and supports both Key Flexfields and Descriptive Flexfields by assembling, parsing, and validating the dynamic SQL required to present, secure, and validate flexfield segments and their values. The package implements the low-level routines that forms and APIs rely on when a flexfield window is opened, when combinations are validated, and when value sets are queried. Because it is classified as OTHER and carries a private-scope header, it is treated as a supporting internal package rather than a public API; nevertheless, eleven other packages reference it, confirming its central role in the flexfield infrastructure. Central to its behavior is the distinction between stored values (as persisted in the database) and displayed values (rendered according to the user's NLS settings), a concept reflected in its FlexValue record type and in the STORED_DATE_FORMAT routine.

Key Procedures and Functions

• STORED_DATE_FORMAT — the routine associated with the search term "stored_date_format"; it derives the date format used for values as stored in the database, independent of the runtime NLS display format.
• PARSE_WHERE_TOKEN — parses tokens embedded in where-clause text so they can be resolved into SQL fragments.
• CHECK_COMB_VRULES — evaluates cross-validation rules for a flexfield combination.
• VALS_SECURED — determines whether value-set security applies to the values being processed.
• VALIDATE_STRUCT — validates the structural definition of a flexfield.
• TO_STRINGARRAY / FROM_STRINGARRAY and TO_STRINGARRAY2 / FROM_STRINGARRAY2 — convert between internal arrays and delimited string representations used by the SQL generator.
• X_INRANGE_CLAUSE, SELECT_CLAUSE, X_COMPARE_CLAUSE — build the SQL fragments (range predicates, select lists, comparison predicates) that make up generated flexfield queries.
• X_DSQL_EXECUTE, X_DSQL_SELECT_ONE, X_DSQL_SELECT — execute dynamic SQL through DBMS_SQL for inserts/updates and for single-row and multi-row selects.
• ISA_NUMBER — tests whether a value is numeric, supporting validation of numeric value sets.
• INIT_GLOBALS — initializes package-level global state for a flexfield operation.
• ADD_SQL_STRING — appends generated SQL text to the accumulating statement buffer.
• GET_NSQL_INTERNAL / GET_SQL_INTERNAL — internal accessors that return generated or stored SQL for a flexfield.

Tables Accessed

The package reads the flexfield definition and metadata tables to drive SQL generation and validation. FND_ID_FLEX_SEGMENTS supplies segment definitions, column mappings, defaulting, security flags, and value-set assignments; FND_DESCRIPTIVE_FLEXS and FND_DESCRIPTIVE_FLEXS_TL provide descriptive flexfield titles and language-specific text; FND_DESCR_FLEX_CONTEXTS and FND_DESCR_FLEX_COLUMN_USAGES describe context and column usage; FND_FLEX_VALUE_SETS and FND_SEGMENT_ATTRIBUTE_VALUES define value-set properties and segment attributes. Validation metadata is drawn from FND_FLEX_VALIDATION_QUALIFIERS, FND_FLEX_VALIDATION_TABLES, and FND_VALUE_ATTRIBUTE_TYPES. FND_TABLES and FND_COLUMNS provide physical column names, types, and widths that feed into the generated SQL and the SegmentInfo record. DBMS_SQL and PLITBLM are used as runtime utilities for dynamic SQL and index-by table handling.

Usage Notes

FND_FLEX_SERVER1 is invoked indirectly whenever a user opens a flexfield window, validates a flexfield combination, or queries a value set in an Oracle Forms session. The Forms runtime passes context to the package, which generates and executes the appropriate SQL against the base application tables. It is also called by concurrent programs and by other FND packages that require server-side validation, SQL generation, or stored-versus-displayed value conversion. Custom code should not call this package directly; developers should use the documented flexfield APIs (such as FND_FLEX_* public interfaces) instead. The header revision (120.22.12010000.2) applies across the 12.1.1 and 12.2.2 releases, so behavior relating to stored date formats and SQL generation is consistent between these versions.