Search Results cl_file_type

Overview

IGF.IGF_SL_CL_FILE_TYPE is a seed-data table in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environments, owned by the IGF schema (the Federal Student Aid / CommonLine processing component delivered with Oracle Financials and its Student Systems lineage). The table maintains the mapping between a CommonLine release version, a CommonLine flat-file type, and the file identification code and name that must be written into or read from that file. In other words, it is the lookup that tells the CommonLine processor which literal file-identification code (for example, the code placed in a file's header or trailer record) belongs to a given version-and-file-type combination, and whether the definition applies to production or non-production processing.

Because it holds relatively static reference values rather than transactional rows, the table functions as a reference/seed object. Under a heuristic Data Vault classification mined from the foreign-key structure, this object is modeled as a standalone — it participates in no documented foreign-key relationships, and its role is best expressed as a small reference dimension or lookup rather than a hub, link, or satellite. When integrated into a warehouse model it would most naturally be treated as a static reference table keyed by version and file type.

Key Information Stored

The table is defined in the APPS_TS_SEED tablespace, has a PCT Free of 10, and contains ten documented columns. The most important are:

• CL_VERSION (VARCHAR2, 30) — the CommonLine version to which the file definition belongs; part of the business key.
• CL_FILE_TYPE (VARCHAR2, 30) — the CommonLine file type; part of the business key.
• FILE_IDENT_CODE (VARCHAR2, 30) — the CommonLine file identification code, the value the user searched for. This is the literal code emitted in or validated against the flat file.
• FILE_IDENT_NAME (VARCHAR2, 30) — the human-readable name associated with that identification code.
• PRODUCTION (VARCHAR2, 30) — flags whether the entry describes a production file, with documented values of Y or N.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Who columns that record row ownership and audit history.

The primary key is IGF_SL_CL_FILE_TYPE_PK (CL_VERSION, CL_FILE_TYPE), and a unique index IGF_SL_CL_FILE_TYPE_U1 (CL_VERSION, CL_FILE_TYPE) reinforces the same business-key candidate. There is no separate single-column surrogate key; the composite of version and file type serves as the business identifier. The FILE_IDENT_CODE and FILE_IDENT_NAME columns are attributes of that key combination rather than keys themselves.

Common Use Cases and Queries

Typical usage centers on resolving, validating, or reporting the file identification code for a given CommonLine version and file type. A common lookup pattern is:

• Retrieving the identification code and name for a specific version and file type: SELECT cl_version, cl_file_type, file_ident_code, file_ident_name FROM igf.igf_sl_cl_file_type WHERE cl_version = :version AND cl_file_type = :file_type;
• Filtering to production definitions only: add AND production = 'Y' to the predicate.
• Producing a reference listing of all supported version and file-type combinations for release documentation or migration verification.
• Validating inbound or outbound flat files by confirming that the code found in the file matches FILE_IDENT_CODE for its declared version and type.

Because the table is seed data, it is also used during upgrades and patch analysis to compare the delivered set of version and file-type rows against customizations.

Related Objects

The documented dependency data states that IGF.IGF_SL_CL_FILE_TYPE does not reference any other database object and is referenced only by the APPS synonym IGF_SL_CL_FILE_TYPE. Consequently, there are no documented foreign-key join columns to other tables. In practice, the columns CL_VERSION and CL_FILE_TYPE are the natural join keys to other CommonLine seed and configuration tables within the IGF schema, and CL_FILE_TYPE plus FILE_IDENT_CODE are the values carried into the actual flat files processed by the CommonLine programs. Cross-schema reporting typically accesses the object through its APPS synonym rather than by direct owner-qualified reference.