Results for “igs_co_s_ltr_pr_arg”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_CO_S_LTR_PR_ARG is a table in the IGS (Student System) product schema of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. It holds a mapping between the bind variables referenced inside the CODE_BLOCK column of the system letter parameter type table and the actual variables available in the PL/SQL function that executes the dynamically constructed SQL derived from that code block. In practice, the table acts as a binding registry that lets the letter-generation engine resolve which host variables in the invoking function correspond to which placeholders when dynamic SQL is assembled and parsed.

From a modeling perspective, the metadata classifies this object as satellite-leaning. Under a Data Vault interpretation, it behaves primarily as a descriptive satellite attached to the parent letter parameter entity, recording directional and binding attributes for each parameter type. Its composite primary key, IGS_CO_S_LTR_PR_ARG_PK, is composed of S_LETTER_PARAMETER_TYPE and BIND_VARIABLE, which also appears as the unique index IGS_CO_S_LTR_PR_ARG_U1, making that pair the natural business key.

Key Information Stored

The documented physical schema for 12.1.1 lists eight columns. The most significant are:

• S_LETTER_PARAMETER_TYPE — Identifier of the system letter parameter type. This is the foreign key column referencing IGS_CO_S_LTR_PARAM and forms the leading component of the primary and unique keys.
• BIND_VARIABLE — The name of the bind (host) variable exposed in the calling function; combined with the parameter type it completes the business key.
• DIRECTION — Indicates the usage direction of the bind variable (for example input versus output) relative to the dynamic SQL execution.
• CREATED_BY / CREATION_DATE — Standard EBS audit columns capturing who created the row and when.
• LAST_UPDATED_BY / LAST_UPDATE_DATE / LAST_UPDATE_LOGIN — Standard EBS audit columns capturing the last modifying user, timestamp, and login session.

The surrogate primary key constraint is IGS_CO_S_LTR_PR_ARG_PK; the unique business-key candidate is IGS_CO_S_LTR_PR_ARG_U1 over (S_LETTER_PARAMETER_TYPE, BIND_VARIABLE). No standalone surrogate column is documented, so the composite key serves both roles.

Common Use Cases and Queries

Typical use is diagnostic and configuration-oriented: developers and administrators inspect which bind variables a letter parameter type expects, or verify that the variables declared in a calling function align with the code block. A representative query joins the argument registry to its parent parameter table:

• Retrieve all bind variables for a parameter type:
  SELECT BIND_VARIABLE, DIRECTION FROM IGS.IGS_CO_S_LTR_PR_ARG WHERE S_LETTER_PARAMETER_TYPE = :p_type;
• Join to the parent to resolve parameter context:
  SELECT a.S_LETTER_PARAMETER_TYPE, a.BIND_VARIABLE, a.DIRECTION FROM IGS.IGS_CO_S_LTR_PR_ARG a, IGS.IGS_CO_S_LTR_PARAM p WHERE a.S_LETTER_PARAMETER_TYPE = p.S_LETTER_PARAMETER_TYPE;
• Audit recent maintenance using LAST_UPDATED_BY and LAST_UPDATE_DATE to track configuration changes.

Reporting use cases include validating letter templates before deployment, troubleshooting dynamic SQL binding errors, and documenting the interface contract between configuration data and custom letter functions.

Related Objects

The principal relationships are defined through the documented foreign key:

• IGS_CO_S_LTR_PARAM — Parent table; joined via IGS_CO_S_LTR_PR_ARG.S_LETTER_PARAMETER_TYPE = IGS_CO_S_LTR_PARAM.S_LETTER_PARAMETER_TYPE. This is the sole documented foreign key.
• IGS_CO_S_LTR_PR_ARG_PK — Primary key constraint on (S_LETTER_PARAMETER_TYPE, BIND_VARIABLE).
• IGS_CO_S_LTR_PR_ARG_U1 — Unique index defining the business-key candidate.
• System letter parameter type table — The logical entity holding the CODE_BLOCK that consumes these bind variables.
• Custom PL/SQL letter functions — External callers that declare the host variables mapped by BIND_VARIABLE.

Because the documented schema contains only one foreign key, broader dependency analysis should focus on the parent parameter table and the letter-generation code that consumes this registry.