Physical Instance Lists

Visual LANSA Framework

Physical Instance Lists

As a developer it may be useful to understand how the actual instance list data content is physically stored and processed.

Some basics of the physical side of instance lists (also see Programmatic Identifiers earlier in this section):

  • An instance list entry is defined and accessed by a programmatic identifier made of up to 5 alphanumeric and 5 numeric values. These are usually referred to as AKey1 -> AKey5 and NKey1 -> NKey5.
  • The composite key that uniquely defines an instance entry is composed of AKey1-NKey1-AKey2-NKey2-AKey3-NKey3-AKey4-NKey5-AKey5-NKey5.
  • Every instance list entry has this 10-part key, even when you do not specify all the keys. For example, when adding SECTIONS to the example instance list, only AKey1(#DEPTMENT) and AKey2(#SECTION) are normally specified. When this is done, AKey3(' ') -> AKey5(' ') and NKey1(0) -> NKey5(0) are used as parameter default values to form the full 10-part key.
  • The preceding point means that if you really want to use a blank AKeyn() values or zero NKeyn() values as part of a real key then it may be problematic. In such cases you should consider using something like AKey4('<BLANK>') and/or NKey2(-9999) to logically represent blank or zero as real non-blank and non-zero key values. 
  • The AKeyn() and NKeyn() values are purely conceptual. You can compose them in any way you feel is appropriate. For example, if you have a need for more than 5 AKeyn() keys, concatenate 2 or more of them together into a single AKeyn() value. For example the SECTIONS-EMPLOYEES instance list could have been structured with this key usage protocol - AKey1 is (#DEPTMENT + "." + #SECTION) and AKey2 is (#EMPNO).   

In the shipped SECTIONS business object the key usage protocol is defined as AKey1 = Department Code and AKey2 = Section Code.

In the shipped EMPLOYEES business object the key usage protocol as AKey1 = Department Code, AKey2 = Section Code and AKey3 = Employee Number.

This means there is a structured key relationship between a parent SECTION and child EMPLOYEE. 

If you are trying to visualize the physically mixed SECTIONS/EMPLOYEES instance list in your mind, imagine the entries looking something like this:

 

Business Object Type AKey1 AKey2 AKey3 Visual ID1 Visual ID2

SECTIONS

ADM 01

 

ADM

01

EMPLOYEES

ADM 01 A1001

A1001

BEN JONES

EMPLOYEES

ADM 01 A1012

A1012

PATRICK PAUL

SECTIONS

ADM 02

 

ADM

02

EMPLOYEES

ADM 02 A0090

A0090

FRED BLOOGS

EMPLOYEES

ADM 02 A1014

A1014

JOHN MOORE

SECTIONS

LEG 01

 

LEG

01

EMPLOYEES

LEG 01 A1019

A1019

CHARLES DICKENS

etc

 

 

 

 

 

 

This key structure relationship between parent SECTIONS and child EMPLOYEES is absolutely vital to being able to process instance lists sensibly, and to displaying them in Visual LANSA tree controls.  Also see Planning parent-child relationships.

There are some things about this physical instance list that are worth noting: