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 you use a logical database to create a new InfoSet, the structure of the logical database (how its tables are arranged in the tree) is read once from the corresponding system tables and stored in the InfoSet. This structure is accessed whenever relationships between tables are analyzed, for example, when query reports are generated. Each time an InfoSet is generated or the InfoSet maintenance is called, the structure of the logical database is read again and compared with the structure that is stored in the InfoSet. The InfoSet can subsequently be adjusted to match any modified structures.
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, fewer options if you need to adjust an InfoSet to a change that has been made to the structure of the logical database. As long as the change to the structure is nothing more complex than the insertion of a new table in the tree, the process to adjust the InfoSet is fairly simple, and the system does not display any messages telling you what steps it has taken.
In the following, more complex cases, a message is displayed and the InfoSet must be checked and possibly revised.
If a table has been removed from the structure and the selected fields of this table are not used in queries, the table and the selected fields are removed from the InfoSet automatically. It is, however, still important to run 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 be removed.
If the structure of tree has been changed in such a way that the relationships between individual tables have also changed, the sections of code and the WHERE conditions in 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) have now changed and consequently, a different set of fields is now available.
These kinds of changes can be very critical. You can no longer be sure that the queries using the InfoSet still function exactly as they used to. You therefore have to checked and modify these queries wherever necessary.
If a table has been removed from the structure and the fields of this table are used in queries, you are not able to regenerate or change the InfoSet. The InfoSet has become practically useless.
In cases like this, you use thefunction to branch to the initial screen for the component and find out which queries use the deleted table (the name of the table that each query uses is displayed on the screen). You must either delete these queries, or change them so that they no longer read data from the deleted table. Finally, you regenerate the InfoSet or make further changes.