Precomputed result sets do not necessarily remain synchronized with the base tables from which they are constructed, and must also be refreshed, either automatically or manually.
refresh {precomputed result set | materialized view} [owner_name.]prs_name
If the schema of any of the base tables from which the precomputed result set is derived has changed, or if it was dropped and re-created (that is, the object ID has changed), the refresh command fails and returns an error indicating the precomputed result set must be dropped and re-created.
Only the owner of the precomputed result set can use the refresh command. If a user has permission to update the base table, he or she can also maintain the precomputed result set.
In most situations, the optimizer should use precomputed result sets with immediate refresh instead of manual refresh for query rewriting (unless you set materialized_view_optimization to stale).
Manually refreshing the precomputed result set is best when you control when insert, update, and delete statements occur. After they occur, perform a planned manual refresh of the precomputed result sets, then use the precomputed result sets to help your read-only applications. However, be aware of the time and extra disk space required to perform a manual refresh and plan accordingly.
create table t1 ( c1 int, c2 int, c3 char(5))
c1 c2 c3 ----------- ----------- ----- 1 3 Aagg 2 8 Xyz
create table t2 (a1 int, a2 int, a3 char(5))
a1 a2 a3 ----------- ----------- ----- 1 5 Ghr 2 1 Gser 3 6 agfh
create precomputed result set prs_1 unique (t1.c1, t2.a2) as select t1.c1, t2.a2 from t1, t2 where t1.c1=t2.a1
c1 a2 ----------- ----------- 1 5 2 1
c1 a2 ----------- ----------- 1 5 2 1 3 6
c1 a2 ----------- ----------- 1 5 3 6
If SAP ASE rolls back the transaction updating the base table, it also rolls back the immediate update on the base table’s precomputed result set as part of the same transaction.