Subset groups are OPEN/DB's way of representing one-to-many relationships between sets of data within the structure of the Subset. Each group may include fields from a number of files linked together as one-to-one and may also include one or more "Derived fields". However, each one-to-many relationship will start a new group - a new "node" of the Subset. 

The Subset Group is affected by the record Subset groups allow OPEN/DB to retrieve data using the relational structures designed into your database. In most situations, this approach offers performance benefits over the creation of large join files. Take, for example, an "Orders" Subset containing Order header and Order detail files. 

Subset "nodes" are directly related to Subset groups. Each file linked as one-to-many becomes a Subset node as well as being the base-file for a new group. As such, it is treated by OPEN/DB as a potential "based-on" file for a given report. This means that, for any report NOT using fields from higher level groups, OPEN/DB can adapt the Subset structure to use the node file as the "based-on" file just for that report. This eliminates the overhead of processing the higher-level files in the Subset if they are not required for a particular report.

For example, consider an order Subset where the Order Header file is the based-on-file and the Order Details file is linked to it as one-to-many. As the based-on file, OPEN/DB treats the Order Header file as a node. The Order Detail file, because it is linked from Order Header in a one-to-many relationship, is also a node. For reports using only fields available from the order detail group, OPEN/DB can create report programs that exclude the order header file. Processing the order header file is unnecessary for these reports, and OPEN/DB's "node" logic enable the pre-compiler to automatically eliminate this overhead even though the Order Header file is the "based-on" file for the Subset. 

OPEN/DB's node logic allows the design of fewer, but more flexible, Subsets secure in the knowledge that OPEN/DB will ensure that reports process only those data necessary. Node logic is yet another reason for designing Subsets with a "top-down" approach because it is only available where you define one-to-many relationship. 

Note that the benefits of node logic are only available if the correct fields are chose when designing the report. Equally, node logic is easily defeated inadvertently by choosing and using the wrong fields in a report . 

Correct use of user views can help to ensure that correct fields are used by report designers and the benefits of node logic will automatically flow from this.

If you omit this file from the Subset it will be simplified by having fewer fields. The creation and maintenance effort for the user views is similarly reduced. The size of EVERY program which uses this group is reduced (a possible performance factor). If the file has 30 fields, but your Subset needs only one of these, you can leave the file out of the Subset design and evaluate the field as a derived field using a user written I/O module. The internal processing overhead is reduced to the tune of approximately 200 fewer HLL program instructions for every record read at this level of the Subset hierarchy (ie. if the average execution of a report on this Subset (using this file in two links) might expect to process 5,000 records for this group, then the program will execute approximately 1 million fewer HLL program instructions. The size and efficiency of every program that reads this file is improved by up to this margin. The time to load the Subset (when this is necessary from time to time) is reduced. 

Solution 1 - An I/O module 

You can write a simple re-entrant I/O program to process this file. Then, create derived fields for those fields from the file that you require and use the logic to invoke your I/O module to return values for fields. The major advantage of this methodology is the insulation of the Subset, and all its reports, from the database in this file. Should the file ever change, you need only alter/re-compile your I/O module - the Subset and all the report programs are unaffected. 

If using this technique, you should also consider the use of DERIVED instance macros. If you define a single macro to call your I/O module, you can attach this macro to the Derived field. If the situation arose in other Subsets, the same Derived macro would serve your purpose. 

Solution 2 - Create a new logical file, that shares the current access path and has only the field(s) your require, and link this into the Subset instead.