Changes that require building a new Schema Cache file

When must a Schema Cache file be rebuilt?
Changes that require building a new Schema Cache file?

1.   The primary reason why a new Schema Cache file requires rebuilding is timestamp differences.

The Schema Cache is valid only if the time stamp of the Schema Cache file matches the Schema time stamp in the database master block. If the time stamps do not match, or for some reason the Schema Cache file cannot be read, a warning message is issued and the schema is read from the database instead.  Depending on the size of the schema being transmitted from database to remote client system a noticeable pause may be observed.

As a result of an outdated Schema Cache file, it is possible that one or more of the following errors will result:  
Unless there are issues reading the file, these errors indicate that the Schema Cache file (.csh) is out of date and needs to be rebuilt using the SAVE CACHE statement. This will occur when:

• Database schema has changed, for example Data Dictionary, Loading .df, Changing SQL widths with DBTOOL
• Schema permissions have changed, or
• Database dump and load has been performed involving schema definitions (not purely data)

PROCOPY/PRODB/PROREST does not require a new Schema Cache file.

2.  While minor versions between the client and the cache file are allowed, major versions are not. In the event that the client version changes from that of the original cache file, the following error(s) are seen.
The Schema Cache needs to be rebuilt with the SAVE CACHE statement using the same major version as the client.

For further information, refer to the following Articles:

•  How do I create a Schema Cache file?   
•  How to keep the schema cache on the client up to date with the database schema?      

Progress Articles: 

 The -trig parameter fails in combination with -cache at runtime