InfoSets and Structural Changes in a Logical Database 
There should be as few changes as possible made to a logical database. Those that are made should be upwards compatible. This means that tables may be extended to include new fields and that new tables may be incorporated into the tree in such a way that the existing structure does not get changed but forms a subset of the new structure.
When a new InfoSet is created over a logical database, the structure of the logical database (the arrangement of its tables in the tree) is read from the relevant system tables once and is stored in
the InfoSet . Whenever relationships between tables have to be evaluated, for example when query reports are being generated, this structure is accessed. Each time that an InfoSet is generated or the InfoSet maintenance is called, the structure of the logical database is read again and is compared with the structure stored in the InfoSet. This means that an InfoSet can be adapted to changes in the structure at this point.Changes to individual tables (for example new fields, deleted fields, changes to the technical properties of fields) are usually straightforward to handle, since they are easily recognized and evaluated. If necessary, the appropriate warnings and error messages are shown when the generation is taking place.
There are, however, rather more restrictions when it comes to adapting an InfoSet to a change in the structure of a logical database. As long as the change of structure is nothing more than the insertion of a new table in the tree, then this is also a straightforward adaptation that is performed without special messages being issued. But in the cases that are described in the following, a message is output and the InfoSet has to be checked and possibly revised
If a table is removed from the structure and the selected fields of this table have not been used in queries, then the table together with the selected fields are also removed from the InfoSet. It is, however, still important to make a check, since fields from this table may be accessed in sections of code or in WHERE conditions contained in connected additional tables. These references must also be removed.
In the case that the structure of tree is changed so that the relationships between individual tables change, then the sections of code and the WHERE conditions of the additional tables also have to be checked. It is particularly important to note that the access paths in the tree (the paths from the root node to the current node) will now have changed and that therefore the set of fields that can be accessed has also changed. These kinds of changes can be very critical. It is no longer possible to be sure that the queries over the InfoSet still work exactly as they used to. Therefore these must also be checked and revised where necessary.
If a table is removed from the structure and the fields of this table are in use in queries, then it is neither possible to generate nor to change the functional area. The InfoSet can no longer be used in its current form. The Goto
® Query directory function on the initial screen of the InfoSet maintenance component should be called to determine which queries use the table that has been removed (note: this function has been extended to output the tables that are referenced by each query). These queries need either to be deleted or to be changed so that the table that has been removed is no longer referenced. The InfoSet can then be generated or changed again.