Search Results okc_k_accesses_v




Overview
Explore in AI Chat

Overview

OKC_K_ACCESSES_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, registered as VALID and delivered as part of the OKC — Contracts Core product family. The view exposes access-security records attached to contract objects held in the Oracle Contracts repository. Its documented purpose is to present the contents of the OKC_ACCESS_SECURITYS table, while the documented view definition and base-object metadata show that it is constructed over the OKC_K_ACCESSES synonym.

In practice, OKC_K_ACCESSES_V provides a stable, read-oriented interface over the access-control rows that determine which resources (users, groups, or other security principals) may act on a given contract or contract line at a defined access level. Because exposure is provided through a view rather than direct table access, Oracle can evolve the physical storage of access-security data without invalidating customer SQL, concurrent programs, OAF pages, or integration extracts that reference the view. This makes okc_k_accesses_v a frequently cited object when developers and analysts search for contract security information in both 12.1.1 and 12.2.2 environments.

Underlying Base Objects

The ETRM metadata documents OKC_K_ACCESSES as the sole referenced base object, exposed to the APPS schema as a SYNONYM. The view text confirms this relationship directly: every column is selected from the alias CACB, which resolves to OKC_K_ACCESSES, and ROW_ID is produced from that table's ROWID. The documented metadata note describing the view as a "View for table OKC_ACCESS_SECURITYS" reflects the underlying security model of the Contracts module, in which access-security definitions are materialized in the OKC_ACCESS_SECURITYS family of tables; OKC_K_ACCESSES functions as the Contracts Core access table consumed by the view.

Because the view is defined over a single base object with a straight projection — no joins, unions, or aggregations appear in the documented view text — the row cardinality of OKC_K_ACCESSES_V matches that of OKC_K_ACCESSES. Each row in the view corresponds to exactly one access-security row. This one-to-one mapping means performance characteristics closely track the base table, and filtering, sorting, or indexing strategies applied to OKC_K_ACCESSES remain relevant when querying the view.

Key Columns

  • ROW_ID — the ROWID of the underlying OKC_K_ACCESSES row; useful for precisely identifying a physical record, though it should not be stored persistently in custom tables.
  • ID — the surrogate primary key of the access record.
  • OBJECT_VERSION_NUMBER — the optimistic locking version counter, incremented on each update; essential for concurrency control in any program that reads and later updates access data.
  • GROUP_ID — identifies the security group associated with the access record, supporting group-based access assignment.
  • CHR_ID — the contract (or contract hierarchy) identifier to which the access record applies; this is the principal join key back to contract header data.
  • RESOURCE_ID — identifies the resource, typically a user or role, granted the access.
  • ACCESS_LEVEL — the level of access granted, defining the degree of visibility or modification permitted to the resource.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns recording who created and last modified the row, the corresponding timestamps, and the login context of the last update.

Common Use Cases and Queries

Typical uses include security audits that enumerate who can see or change a contract, extract programs that replicate contract access rules into external systems, and diagnostic queries that reconcile access records against expected organizational policy. The following examples illustrate standard access patterns.

List all access records for a specific contract:

SELECT id, chr_id, resource_id, access_level, last_update_date
FROM okc_k_accesses_v
WHERE chr_id = :contract_id;

Identify all contracts visible to a given resource:

SELECT chr_id, access_level
FROM okc_k_accesses_v
WHERE resource_id = :resource_id;

Audit recently modified access grants:

SELECT id, chr_id, resource_id, access_level, last_updated_by, last_update_date
FROM okc_k_accesses_v
WHERE last_update_date >= SYSDATE - 30
ORDER BY last_update_date DESC;

Because the view carries no WHERE clause of its own, all filtering must be supplied by the calling query; a restrictive predicate on CHR_ID, RESOURCE_ID, or GROUP_ID is advisable to avoid full scans of the base access table in high-volume environments.