LANSA file definitions can contain 3 types of fields:
These are the normal fields found in any IBM i file definition and are assembled together to form the record format of the associated physical file. Such fields actually exist in the database file and their content (or value) can be extracted from any record in the file at any time.
These are fields that do not actually exist in the IBM i database file, but are dynamically derived from "real" fields in the file.
For information, refer to 3.14.1 What Is a Predetermined Join Field? in Access Routes to Other Files.
The distinction between "real" and "virtual" fields can be best illustrated by example.
Consider an accounting file called ACCMST that contains an 8 digit field called CHTACC (chart of accounts) that looks like this:
_________________________________
| 0 | 8 | 6 | 3 | 4 | 3 | 1 | 2 |
_________________________________
This example is for chart of accounts number 08634312. In actual fact the chart of accounts has 3 components. These are: a 2 digit company number (08), a 2 digit division number (63), and a 4 digit cost center (4312).
Since the company number, division number and cost centre can be "derived" directly from the chart of accounts number it would be possible to define in file ACCMST three "virtual" fields called COMPNO, DIVNUM and COSTCT.
If this was done the definition of file ACCMST would contain:
|
Of course there is a missing link. That is the definition of how virtual fields COMPNO, DIVNUM and COSTCT are "derived" from the real field CHTACC.
There are two methods available that allow you to specify how a virtual field is derived.
The first method is the "Extended definition of virtual fields" function, which allows you to perform the most commonly used actions to derive virtual fields from real fields and vice versa, these actions are as follows:
The "Extended definition" function of virtual fields is described elsewhere in this guide.
The second method in specifying how virtual fields are derived from real fields and vice versa is achieved by entering RPG/400 program code. This method is the simplest and by far the most flexible method of specification for more complex actions such as:
In this example the virtual fields COMPNO, DIVNUM and COSTCT could have been derived by using the "Extended definition of a virtual field" function by Substringing the real field into CHTACC OR by entering a few lines of RPG/400 code that mapped field CHTACC into fields COMPNO, DIVNUM and COSTCT.
Once this has been done COMPNO, DIVNUM and COSTCT would appear to be in file ACCMST. However, if the file was examined it would be found that the fields do not actually exist. Hence the name "virtual" fields.
Note that fields COMPNO, DIVNUM and COSTCT are only used when reading (i.e. inputting) from the ACCMST file. When writing to or updating the ACCMST file they have no particular meaning.
This need not be so, in fact virtual fields COMPNO, DIVNUM and COSTCT could be used to "re-assemble" field CHTACC when outputting to the file. This feature of virtual fields is extremely useful in some situations. Refer to Virtual Fields for more details and examples.
