Search Results fnd_conc_request_arguments

Overview

FND_CONC_REQUEST_ARGUMENTS is a table owned by the APPLSYS schema in Oracle E-Business Suite, belonging to the FND — Application Object Library product. It stores arguments 26 through 100 for concurrent requests submitted to the Concurrent Manager. Because the companion FND_CONCURRENT_REQUESTS table historically accommodated only the first 25 arguments, this satellite table was introduced to hold the overflow range, allowing a single concurrent program to accept up to 100 parameters without altering the primary request header structure.

The table is documented in both ETRM 12.1.1 and 12.2.2 and holds a status of VALID. Its physical schema comprises 76 columns: a single REQUEST_ID column acting as both the primary key and the foreign key, plus ARGUMENT26 through ARGUMENT100. The presence of a unique index FND_CONC_REQUEST_ARGUMENTS_U1 on REQUEST_ID, together with a foreign key to FND_CONCURRENT_REQUESTS, indicates a strict one-row-per-request cardinality. Under Data Vault classification heuristics this object is best modeled as satellite-leaning: its grain is defined entirely by the parent request identifier, and it contributes descriptive, non-key attribute data (individual argument values) rather than introducing new entities or relationships.

Key Information Stored

The documented columns fall into two conceptual groups:

• REQUEST_ID — The surrogate primary key of the table and simultaneously the foreign key to FND_CONCURRENT_REQUESTS. It uniquely identifies the concurrent request whose overflow arguments are stored in this row. Because the unique index FND_CONC_REQUEST_ARGUMENTS_U1 covers REQUEST_ID alone, the business-key candidate is the request identifier itself rather than any combination of argument columns.
• ARGUMENT26 through ARGUMENT100 — Seventy-five positional columns, each holding the character representation of one concurrent program parameter. Argument values are stored positionally, so the meaning of, for example, ARGUMENT47 is determined entirely by the parameter definition of the concurrent program associated with the parent request. Values may represent dates, numbers, or text, always persisted as strings and later converted by the program's parameter validation logic.

No additional descriptive columns (such as timestamps or user identifiers) are documented; such audit information resides on the parent FND_CONCURRENT_REQUESTS row.

Common Use Cases and Queries

Typical scenarios include reconstructing the full parameter set of a submitted request, auditing what values were supplied to long-parameter concurrent programs, and reproducing a prior run by copying its arguments.

Joining the overflow arguments to the request header is the canonical access pattern:

• SELECT r.request_id, r.concurrent_program_id, a.argument26, a.argument27 FROM fnd_concurrent_requests r JOIN fnd_conc_request_arguments a ON a.request_id = r.request_id WHERE r.request_id = :request_id;
• Identifying requests that actually use the overflow range: SELECT request_id FROM fnd_conc_request_arguments WHERE argument26 IS NOT NULL;
• Reporting on a specific positional argument across many requests: SELECT request_id, argument50 FROM fnd_conc_request_arguments WHERE argument50 = :value;

Because argument columns are generic text, queries should apply appropriate conversion functions when the underlying parameter is typed. Note also that rows are typically created only when the concurrent program defines more than 25 parameters, so the table's population density is low relative to FND_CONCURRENT_REQUESTS.

Related Objects

• FND_CONCURRENT_REQUESTS — The parent table; joined on REQUEST_ID. This is the sole documented foreign key relationship and the primary source of context such as program, phase, and status.
• FND_CONCURRENT_PROGRAMS — Provides the parameter definitions that give positional meaning to ARGUMENT26–ARGUMENT100, joined indirectly through the parent request's CONCURRENT_PROGRAM_ID.
• FND_PROGRAM_PARAMETERS — Defines each parameter's sequence, datatype, and validation, allowing mapping of stored argument positions to business meaning.
• FND_CONCURRENT_REQUEST_ARGUMENTS_U1 — The unique index enforcing one row per REQUEST_ID.
• FND_CONC_REQUEST_ARGUMENTS_PK — The primary key constraint on REQUEST_ID.

Together these objects allow a complete, ordered reconstruction of concurrent request parameters spanning both the primary argument columns and the overflow range documented here.