Search Results section_sequence




Overview
Explore in AI Chat

Overview

APPS.OKC_SECTIONS_INDEX_V is a reporting and integration view in Oracle E-Business Suite that exposes a hierarchical, tree-indexed representation of contract sections stored in the OKC (Oracle Contracts) schema. Its central purpose is to flatten the self-referencing structure of the OKC_SECTIONS_B table into a single result set that carries a computed positional index and a padded ordering key for each section. This makes the view particularly valuable for downstream consumers — BI Publisher reports, OAF pages, SOA integrations, and custom concurrent programs — that need to render contract sections in their correct logical sequence without implementing recursive traversal logic themselves.

The user search term "section_sequence" corresponds directly to a column of the underlying OKC_SECTIONS_B table that the view passes through the OKC_TREE_INDEX package functions. In practice, section_sequence is the ordinal attribute that determines sibling ordering at each level of the contract section hierarchy.

Underlying Base Objects

The view is defined over two documented base objects:

  • OKC_SECTIONS_B (SYNONYM) — the base table holding contract section definitions, including the ID primary key, the SCN_ID (parent section) foreign key, the CHR_ID (contract header) reference, and the SECTION_SEQUENCE ordering attribute.
  • OKC_TREE_INDEX (PACKAGE) — a PL/SQL package supplying the hierarchical helper functions GET_ID, GET_ID_LPADED, and GET_ROOT_ID used to compute the derived index and ordering columns.

The view's SELECT uses an Oracle CONNECT BY hierarchical query: CONNECT BY PRIOR ID = SCN_ID START WITH CHR_ID = OKC_TREE_INDEX.GET_ROOT_ID AND SCN_ID IS NULL. This anchors the traversal at the synthetic root identifier returned by GET_ROOT_ID, then walks downward through each level via the parent-child relationship between SCN_ID and ID. Because the query does not restrict CHR_ID to a single contract, the view conceptually spans all contract headers, with each row scoped by its own CHR_ID value.

Key Columns

  • ID — the primary key of the contract section row from OKC_SECTIONS_B.
  • SECTION_INDEX — computed by OKC_TREE_INDEX.GET_ID(LEVEL, SECTION_SEQUENCE). It produces a hierarchical positional identifier that combines the CONNECT BY pseudo-column LEVEL with the sibling sequence, yielding a value suitable for sorting and for displaying outline-style indices.
  • SECTION_ORDER — computed by OKC_TREE_INDEX.GET_ID_LPADED(LEVEL, SECTION_SEQUENCE, 5, 2). The LPADED variant left-pads the level and sequence components to fixed widths (5 and 2 respectively), guaranteeing lexicographic string comparison matches numeric hierarchical order — essential when ordering mixed-depth nodes.

Implicitly, the driving CHR_ID, SCN_ID, and SECTION_SEQUENCE values from OKC_SECTIONS_B remain available through the SELECT list even though the excerpt shows only the three computed expressions.

Common Use Cases and Queries

Typical scenarios include rendering contract section outlines, generating clause ordering reports, and feeding integration payloads where the section sequence must be preserved.

  • Retrieve all sections ordered hierarchically: SELECT id, section_index, section_order FROM apps.okc_sections_index_v ORDER BY section_order;
  • Join back to the base table for descriptive attributes: SELECT v.section_order, s.section_sequence, s.id FROM apps.okc_sections_index_v v, apps.okc_sections_b s WHERE v.id = s.id ORDER BY v.section_order;
  • Constrain to a single contract header by joining on CHR_ID in OKC_SECTIONS_B, since the view itself is not filtered by contract.

Because the view performs a CONNECT BY over the full sections table, queries should generally include a CHR_ID predicate (via join or inline view) to avoid full-tree scans in production environments.