When opening a table through the driver, information on the table definition will be assembled. The information will be obtained from the meta database. Since this involves a number of database find operations, it may take some time to get all this information. In general, table definitions are very static, especially in a deployed environment. For this reason, structure caching was implemented. Structure caching will dramatically speed up the opening of tables. It stores the table definition in a disk file (*.cch) and reads this disk file instead of getting the information from the meta database.
Storing information in two places is always dangerous. It is possible for the cache to get “out of sync” with the actual table definition. The structure cache mechanism was designed to prevent this from happening as much as possible.
Since environments and requirements vary between different installations, structure cache behavior can be setup through the driver configuration file.
Structure caching will store all information (table, column and index) of a table in a cache file (*.cch) when the table is first opened through the driver. The next time the table is opened, this cache file will be used to get the structure information instead of using the meta database.
By default, the structure cache files will be placed in the same directory as the intermediate file for the table. You can specify a cache path in the driver configuration file. If this path is defined, it must point to a valid directory. All cache files will be placed in that directory.
Cache paths can be used for easy maintenance or when using multiple drivers. Other drivers also support a structure cache mechanism. In a mixed environment it may be needed to give each driver its own cache directory.
Cache files can get “out of sync”. There are a number of reasons why this happens. Most of the time the driver will automatically detect the “out of syncness” and regenerate the cache file automatically. The reasons why a cache file will get “out of sync” are:
The intermediate file changes.
A restructure operation was done through the DataFlex API
The table definition changes not using the driver to make the definition change.
The driver uses a new cache format.
Most of the cases above will be handled automatically.
The cache mechanism will compare the timestamps of the cache file and the intermediate file. If the intermediate file is newer than the cache file, the cache file will be regenerated. You can switch off the timestamp check in the driver configuration file.
When a restructure operation is done, the cache file will be deleted. Upon the next open of the table, the cache file will be regenerated.
Every cache file contains a signature. This signature defines the format of the cache file. When a cache file is opened but the signature does not comply with the expected format, the cache file will be regenerated.
The only situation that is not automatically detected and handled is when table definition changes are made outside the driver. In that case the cache files of the changed tables should be deleted. When the tables are opened the next time, a new cache file will be generated.
It is always allowed to delete cache files, they will be regenerated automatically.