Limitations of Snapshot Table Views

Snapshot table views have the following limitations:

  • If an attribute’s value is invalid, it will appear as NULL in a snapshot table. Snapshot table columns are typed for the datatype defined for the attribute in the repository’s profile. Therefore, a snapshot table column can only hold data appropriate to its type. If an attempt is made to store an attribute value in a snapshot table that does not match its defined datatype or if the value is otherwise invalid, the value NULL will be stored.

  • Snapshot tables are limited by the database’s constraints of 1022 columns and 8060 bytes per row.

  • Snapshot tables are read-only .

  • Snapshot tables are volatile . A number of data model changes can cause a snapshot table to be rebuilt, which can affect permissions granted to users to access the table.

  • If you define your own views on top of a snapshot table view, if the snapshot table gets rebuilt, you will lose your views. You need to have a process in place to rebuild your views.

  • The snapshot table indexes you define through the EnterWorks UI are on individual attributes. If you need composite indexes, you have to define them separately from EnterWorks, though there are tools in Services Framework for helping maintain composite indexes.

  • If the snapshot table gets rebuilt, your composite indexes will not be rebuilt automatically.

  • Multi-language category attributes must be included in the main snapshot table in order for the multi-language snapshot table values to be kept. They will not be built from the category attribute snapshot table; you have to explicitly add them to the main snapshot table.

  • If there are many attributes in the snapshot table, it can take longer for EnterWorks to update the repository. When an attribute in a snapshot table is updated, it is updated in two places: the repository record and the snapshot table. If a lot of attributes in the snapshot table need to be updated at once, it may affect EnterWorks’s performance.