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 functional area 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 functional area. Whenever relationships between tables have to be evaluated, for example when query reports are being generated, this structure is accessed. Each time that a functional area is generated or the functional area maintenance is called, the structure of the logical database is read again and is compared with the structure stored in the functional area. This means that a functional area 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. Warnings and error message are issued where necessary during the generation process.

There are, however, rather more restrictions when it comes to adapting a functional area 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 functional area 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 functional area. 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 functional area still work exactly as they used to. Therefore these must also be checked and revised where necessary.