View RSS Feed

Development Team Blog

INT and CCH Files Explained

Rate this Entry
When using the Connectivity Kits, we hear a lot about intermediate (INT) files and structure cache (CCH) files, but the role that those files play in the Connectivity Kit world seems to not be completely understood.

What is an INT file?
INT files are text files that contain the driver name to be used to open a table, the table's connection information (server, database, etc) and identification (table name, schema, etc), and some special information (e.g. whether the table is a system table, a recnum table; the columns that are hidden, overlap; index numbers) DataFlex needs but cannot get from the table (i.e. database server) itself. In other words, INT files will complement or adjust the information read from the database backend.

As the Help explains, the contents of an intermediate file can be divided into three sections:
  1. A section that allows Visual DataFlex to determine which database driver to use (Driver_Name part of the harder)
  2. A section that contains information needed before a table can be opened (the remaining information in the header)
  3. A section that contains information needed after a table has been opened (table, column and index keywords in the body of the INT)
It is possible to open a table without using an intermediate file as long as the very basic information (driver to be used, table schema and name, and connection string) is provided. This way (if no CCH file is present) the table structure you read will be coming solely from the backend.

That means INT files have little, if any, influence on what the table structure is. Besides being the header (connection string) keeper and the storage for things the Connectivity Kits cannot get from the backend server and DataFlex needs, they may modify or tweak the table definition a bit. For example, a column length in DataFlex can be changed from what the Connectivity Kit read from the backend to whatever definition you specified using Field_Length in the INT for that column.

What is a CCH file?
CCH files contain all information about the structure of a table. They are created as part of the structure cache mechanism implemented by the Connectivity Kits.

When a table is opened through the Connectivity Kit, if the table does not have a CCH file, or the existing one needs to be recreated (i.e. it is older than its INT counterpart or has a different driver signature in it), the driver will assemble the information read from the INT file and the backend server into a new CCH. Once a CCH file is present, the Connectivity Kit will use it at every open; it will read the header from the INT file and then read everything else from the CCH. This will speed up table opens as the driver does not need to go through the assembling step every time the table is open.

Sometimes the INT file has the real minimum (connection information) and you have nothing else about the table in them. In that case, the information stored in the CCH will come strictly from the backend.

A group of keywords and attributes dictate whether the cache mechanism should be used and how structure caching works in each environment. You can choose from turning off structure caching completely (Use_Cache or DF_DRIVER_USE_CACHE) to changing the location where the CCH files are to be created (Cache_Path or DF_DRIVER_CACHE_PATH). You can get a full list of those from the Help.

What is important then?
In order to maintain a stable environment and be "in peace" with the Connectivity Kits, it is important to have good CCH files and have the cache mechanism set up correctly to refresh the cached information and find the right INT and CCH files.

To avoid problems, make sure that only one set of INT files can be found by your workspace and that the path specified for the cache files is accessible and correct.

Also, make sure that only one version of the Connectivity Kits accesses the tables of a given workspace, as each version has its own features and requirements. The INT files for each version of the Connectivity Kit, for example, may, and most probably will, be different from one another -- new keywords introduced, and old keywords dropped. Other issues, like difference in data type equivalence between DataFlex and the SQL backend, may also cause problems when you mix Connectivity Kit versions.

On top of that, since CCH files contain the signature of the driver that created them, if you have multiple versions of the Connectivity Kit accessing the same tables, the CCH files will constantly need to be rebuilt, affecting the performance of your applications. You may choose to adjust the CACHE_PATH setting of each version of the Connectivity Kit to store CCH files in different folders, but that is not recommended.

By default, the Connectivity Kits will take care of refreshing the CCH files automatically, but there are situations that manually removing the CCH files is necessary -- when the table definition is changed without using the Connectivity Kit, but using one of the backend management tools, for example.

If the cache files get out of sync, weird things could happen. In that case, the CCH files should be deleted so they can get recreated again using the current information available to the Connectivity Kit. That will happen when the modified tables are opened through the Connectivity Kit the next time.

Updated 15-Dec-2009 at 09:28 AM by Stephen W. Meeley (Spell Check)

Tags: cli, marcia booth, sql