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:

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 relationship in VLF-WIN.

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

• You can add the entries to the instance list in any order

• You can dynamically add children to an instance list "on demand"

• When a child is in the instance list it must have a parent

• You can dynamically update individual entries in a parent-child instance list without collapsing the visual tree

• You can dynamically delete individual entries in a parent-child instance list without collapsing the visual tree

• You can dynamically add individual entries in a parent-child instance list without collapsing the visual tree