Refresh Data window

This window has the following components:

Choose an isolation level to be used for the refresh operation   Select one of the following isolation levels to specify the type of locking to use on the underlying base tables during the refresh. The type of locking determines how the materialized view is populated and how concurrency for transactions is affected.

  • Read uncommitted (level 0)   This option provides the maximum level of concurrency, but dirty reads, non-repeatable reads, and phantom rows may be observed in result sets.

  • Read committed (level 1)   This option provides less concurrency than level 0, but eliminates some of the inconsistencies in result sets at level 0. Non-repeatable rows and phantom rows may occur, but dirty reads are prevented.

  • Repeatable read (level 2)   This option allows phantom rows to occur. Dirty reads and non-repeatable rows are prevented.

  • Serializable (level 3)   This option provides the least concurrency, and is the strictest isolation level. Dirty reads, non-repeatable reads, and phantom rows are prevented.

  • Snapshot   This option uses a snapshot of committed data from the time when the first row is read, inserted, updated, or deleted by the transaction. Snapshot is the default if the view is a manual view and the database is using snapshot isolation.

  • Share mode   This option provides read access on underlying tables to other transactions while the refresh operation takes place. When this clause is specified, shared table locks are obtained on all underlying base tables before the refresh operation is performed and until the refresh operation completes the REFRESH MATERIALIZED VIEW statement.

    Share mode is the default if the view is a manual view and the database is not using snapshot isolation. Share mode is also the default if the view is an immediate view, regardless of whether snapshot isolation is enabled.

  • Exclusive mode   This option places exclusive table locks on all underlying base tables. No other transaction can execute queries, updates, or any other action against the underlying table(s) until the refresh operation is complete. If exclusive table locks cannot be obtained, the refresh operation fails and an error is returned.

    Choose this mode if you do not want to change the isolation level, but want to guarantee that the data is updated to be consistent with committed data in the underlying tables. See REFRESH MATERIALIZED VIEW statement.

See also
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1