Span Access Path

25 Views

Prev
Next

A Span Access Path in Cool:2E (Synon/2E) is a special type of access path used to traverse a one-to-many relationship between two files — typically a parent-child relationship — without using a physical or logical join file.

🧠 What Is a Span Access Path?

  • A Span Access Path is defined on a "Detail" (child) file to automatically navigate from a "Header" (parent) file using a foreign key relationship.

  • It allows you to access all child records for a given parent key in one step, as if you were reading from a keyed logical file based on the parent key.

  • Synon uses the foreign key constraint to understand how to link the records — no need to define a join file manually.

📘 Example Scenario

You have:

  • Header File: CUSTOMER

  • Detail File: ORDERS

    • Foreign key: CUSTOMER_ID

In Synon:

  • On ORDERS, you define a Span Access Path.

  • Synon will automatically allow you to retrieve all ORDERS for a given CUSTOMER_ID, sorted as needed.

✅ Use Case

Used when you:

  • Want to loop over all child records of a parent in a program

  • Don't need filtering or advanced selection — just full child access via the foreign key

  • Want Synon to handle the relationship implicitly

🔧 How to Define a Span Access Path in 2E

  1. Go to YWRKFIL and select the Detail file (e.g., ORDERS)

  2. Use YEDTAP to edit access paths

  3. Add a new access path:

    • Type: SPN (Span)

    • Related file: The parent file (e.g., CUSTOMER)

  4. Select the foreign key relationship that defines how the files are linked

  5. Define the sort sequence if needed (e.g., by order date)

Now, any function using this access path will automatically iterate ORDERS per CUSTOMER.

💡 Behind the Scenes

Synon uses the foreign key defined in the model to:

  • Build implicit selection criteria (ORDERS.CUSTOMER_ID = CUSTOMER.CUSTOMER_ID)

  • Avoid the need for explicit joins or logicals

  • Generate clean, efficient code for programs

🆚 Span vs Query Access Path

Feature Span Access Path Query Access Path
Purpose Traverse child records Filter/sort dynamically
Relationship Uses foreign key No relationship required
Type Static (model-driven) Dynamic (built at runtime)
Typical Use Parent-child read Subset/sorted views

Yes — in Cool:2E (Synon/2E), the "is owned by" relationship is mandatory for defining a Span Access Path.

✅ Why "Is Owned By" Is Required

The Span Access Path relies on the foreign key relationship between the detail file (child) and the header file (parent). In Synon, this relationship must be defined explicitly using:

[Detail file] *is owned by* [Header file]

This defines a one-to-many parent-child relationship in the data model, which is what the Span Access Path uses to function.

🔄 Without "Is Owned By"?

  • If the *is owned by* relationship is not defined, Synon won’t know:

    • Which parent record the detail belongs to

    • What keys to use for the span access path

  • Result: You cannot define a Span Access Path without this relationship.

🧭 Where to Define It

To set up the ownership in Synon:

  1. Go to YWRKREL (Work with Relationships)

  2. Select the Detail file (e.g., ORDERS)

  3. Add a relationship:

    ORDERS *is owned by* CUSTOMER

  4. Specify the key fields that link the two (e.g., CUSTOMER_ID)

Once this is in place, you can then:

  • Create a Span Access Path on ORDERS

  • Reference CUSTOMER as the header (owning) file

  • Use the foreign key automatically

 

Prev
Next
Save ()

Post Comments