Rebuilding Snapshot Tables

Changes to the data model can affect a repository’s snapshot tables, including causing them to be rebuilt. An event that triggers the main snapshot table to be rebuilt will also trigger the category attribute snapshot table and the multi-language support snapshot tables to be rebuilt, if they exist.

Examples of changes that may trigger the snapshot tables to be rebuilt include:

• Changing an attribute’s data type.

• Making an attribute repeatable.

• Adding or removing an attribute from the main snapshot table.

• Changing a code in a Code Set.

Rebuilding the snapshot tables is processed as a background job. Once the job has been started, its progress can be monitored in the Job Monitor.

For a detailed list of data model changes that affect the snapshot tables, see the Precisely EnterWorks Classic System Administration Guide.

When a snapshot table is rebuilt, the view is deleted and a new one is generated. Any users who had access that was explicitly granted to the old view will no longer have access to it, nor will they have access to the new view until that explicit access has been re-granted. This can be avoided by granting general access to the views so if a view is re-created, it can be accessed without being explicitly granted.

Also, rebuilding a snapshot table can take a while. While a snapshot table is being rebuilt or repopulated, only the repository records that have already been added to the snapshot table are available for use. Records that have not yet been added/re-added will be unavailable.

For these and other reasons, data model changes should not be made during the business day. The best practice is to make changes after business hours, when the impact to users is minimal. After changes to the data model are complete and the affected snapshot tables are rebuilt, if you are explicitly granting access to the views, you will need to do so.