Work with Aliases of entry
In relational databases it is very common that relations exist between files. A file is often no more than a means of storing a lot of records of the same type, while the exact relation between individual records is determined in a different way. Suppose the following example where there are two files involved: "Orders" and "Relations":
Orders |
|
Relations |
|||||||
Order ID |
|
Date |
Customer ID |
Account manager ID |
….. |
|
Relation ID |
Name |
….. |
….. |
|
….. |
….. |
….. |
….. |
|
….. |
….. |
….. |
23473856 |
|
20020112 |
237648454 |
789563478 |
….. |
|
237648454 |
Acme Inc. |
….. |
23473857 |
|
20020112 |
948534548 |
457769767 |
….. |
|
….. |
….. |
….. |
….. |
|
….. |
….. |
….. |
….. |
|
457769767 |
Smith |
….. |
|
|
|
|
|
|
|
….. |
….. |
….. |
|
|
|
|
|
|
|
789563478 |
Jones |
….. |
|
|
|
|
|
|
|
….. |
….. |
….. |
|
|
|
|
|
|
|
948534548 |
Insurance Inc. |
….. |
|
|
|
|
|
|
|
….. |
….. |
….. |
In this example the file "Relations" contains information on all relations, e.g., Companies, Organizations, Persons. The connection between the file "Orders" file and the "Relations" is by the "Relation- IDs" stored in the "Orders" file. But there is a paramount distinction between the connections indicated by the "Relation- IDs" in the column: "Customer IDs" and those in the column "Account manager IDs": the relations indicated in these columns play a different role in the particular order. Those in the column: "Customer IDs" indicate the customer that placed the order; those in the column "Account manager IDs" indicate the employee that is responsible for the order.
When describing the example in the ITP/SDK for iSeries one would generate two Entries: Order and Relation. To indicate the connection between Order and Relation one would like to register Relation twice as a Subentry of the Entry Order: one with the Field Customer_ID and one with the Field Account_manager_ID as Actual parameter. However, this is not possible because an Entry can only be registered once in the Subentry list of another Entry. Even if this restriction did not exist it would be confusing to have two Subentries to the Entry Order that are both named Person: which Person would indicate the Customer and which the Account manager?
To solve this problem ITP has the concept of Aliases. An Alias entry is nothing more than another name for an existing Entry, where the name indicates a role the original Entry can play in respect to other Entries. Following the example of Orders and Relations this would lead to:
Alias Entries are the same as Entries defined in the DID-source, but: the only thing that an Alias Entry can be used for is as a Subentry with another Entry.
- Alias entries may not be registered as Main entries (and thus changing the Screen field definitions is not allowed);
- It is not possible to create Subentries for the Alias entry;
- Attributes of Alias entries cannot be changed (and thus they cannot be exported and no offsets may be recalculated);
- Alias Entries cannot be copied or re-generated;
- No data retrieval program may be generated for the Alias entry;
- No Field definitions or Formal parameters may be changed.
Using option "14=Aliases" with an Entry on the panel Work with Entries displays the list of all Aliases of the Entry on the panel "Work with Aliases of entry".
|
Create a new Alias for the Entry. |
|
Delete the Alias Entry. A window with a warning and an extra request for confirmation is displayed if the Entry is still used as a Subentry. This is exactly the same function as when option "4=Delete" is used on the "Work with Entries" panels for the Alias Entry |
|
Display the primary attributes of the Alias Entry. This is exactly the same function as when option "5=Display" is used on the "Work with Entries" panels for the Alias Entry |