Search Results fnd_conc_request_arguments_u1

Overview

APPLSYS.FND_CONC_REQUEST_ARGUMENTS is a core concurrent processing table in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the values of the twenty-sixth through the one-hundredth positional arguments for a concurrent request. Oracle's concurrent manager architecture allows a program to be submitted with up to 100 parameters, and the framework splits storage of those parameters across two tables: the first twenty-five arguments are held in FND_CONCURRENT_REQUESTS, while arguments 26 through 100 are persisted in this table. Consequently, a row exists here only for concurrent requests that supply more than twenty-five arguments, making the table sparse in most production instances.

The object resides in the APPLSYS schema, is marked VALID, and is designated as FND design data (FND.FND_CONC_REQUEST_ARGUMENTS). It is stored in the APPS_TS_TX_DATA tablespace with a PCT Free of 5. From a modeling perspective, the Data Vault classification heuristic suggests a satellite-leaning structure. This reflects the fact that the table carries descriptive, non-key payload (the argument values) keyed to a parent request entity, and does not itself introduce new hubs or represent a many-to-many association between independent business keys.

Key Information Stored

The table comprises 76 documented columns. The most significant columns are:

• REQUEST_ID (NUMBER(15), mandatory) — The request identifier. It is the primary key of the table (FND_CONC_REQUEST_ARGUMENTS_PK) and also the single-column unique index FND_CONC_REQUEST_ARGUMENTS_U1. It is a foreign key to FND_CONCURRENT_REQUESTS, enforcing that argument rows cannot exist without a parent request.
• ARGUMENT26 through ARGUMENT100 (VARCHAR2(240)) — Seventy-five positional argument columns, each holding the text value of the corresponding parameter position for the concurrent request. Each column is non-mandatory and stores the argument value as a character string, regardless of the logical parameter type.

Two points of clarification are important. First, REQUEST_ID is simultaneously the surrogate primary key and the sole business-key candidate, because the unique index and primary key are defined on the same column. There is no separate system-generated surrogate column beyond REQUEST_ID. Second, this table contains no descriptive metadata about the arguments themselves, such as parameter names, prompts, or data types; that information resides in the concurrent program definition tables. This table is purely a value store keyed by request.

Common Use Cases and Queries

The table is consulted primarily for debugging, auditing, and reconstructing the exact parameter set passed to a long-running or high-parameter concurrent program. Typical queries join this table to FND_CONCURRENT_REQUESTS on REQUEST_ID to retrieve the program name, submission time, and argument values together.

A representative pattern retrieves all arguments for a specific request:

• SELECT r.request_id, r.concurrent_program_id, r.argument_text, a.argument26, a.argument27 FROM fnd_concurrent_requests r LEFT JOIN fnd_conc_request_arguments a ON a.request_id = r.request_id WHERE r.request_id = :request_id;

Another common use is locating requests by a distinctive argument value, for example tracing every submission that passed a particular GL period or ledger identifier in position 26 or beyond. Reporting use cases include building custom concurrent program audit reports and reconciling re-run parameters. Because arguments are stored as VARCHAR2, type-sensitive queries against numeric positions require explicit TO_NUMBER conversion with attention to invalid or empty values.

Related Objects

The following objects are most significant in relation to FND_CONC_REQUEST_ARGUMENTS:

• APPLSYS.FND_CONCURRENT_REQUESTS — Parent table. Joined via FND_CONC_REQUEST_ARGUMENTS.REQUEST_ID = FND_CONCURRENT_REQUESTS.REQUEST_ID. Holds request status, program, and arguments 1–25.
• APPLSYS.FND_CONCURRENT_PROGRAMS — Defines the program being run; joined through the parent request's CONCURRENT_PROGRAM_ID to interpret argument meaning.
• APPLSYS.FND_CONCURRENT_PROGRAM_SERIAL — Used by concurrent manager processing alongside request records.
• APPLSYS.FND_CONC_REQUEST_ARGUMENTS_U1 — The unique index on REQUEST_ID that enforces one argument row per request and accelerates lookups.
• APPLSYS.FND_CONC_REQUEST_ARGUMENTS_PK — The primary key constraint on REQUEST_ID.
• APPLSYS.FND_CONCURRENT_REQUESTS (view/reporting surface) — Frequently combined with argument data in standard concurrent manager diagnostics and the Submit Requests forms.

Because the table is a dependent satellite of the concurrent request entity, its lifecycle is governed entirely by the parent request; deleting a request removes its argument row. Administrators maintaining concurrent manager purge routines should account for this dependency when cleaning historical request data.