The Settings tab of a Refreshing or Appending view is where you follow the refresh that keeps its rows current and control the schedule behind it. It also carries the view's statistics.
The Settings tab fills in only after the view is deployed. Until then it reads View Not Deployed with View must be deployed to view settings, and neither statistics nor refresh data load.
Deploy the view first, as described in Views. Once it is deployed, the statistics strip and the refresh panel load.
The strip titled View Statistics sits at the top of the tab. Three cards summarise the stored table:
A card shows - while its value is not available. When a refresh record exists, a status badge next to the heading matches the schedule status, for example Scheduled or Running.
The strip carries the actions:
Under the statistics strip, Refresh Settings shows the state of the view's refresh. The schedule follows the refresh settings on the view's General step; Views lists those fields.
A status badge sits next to the heading, and the actions change with the status:
| Status | Actions |
|---|---|
| Scheduled | Stop Schedule pauses the plan; Synchronize runs a refresh straight away. |
| Running | Cancel Refresh stops the refresh in progress. |
| Disabled | Start Schedule starts the schedule again. |
After you start a refresh, the action switches to Cancel Refresh while it runs.
The panel lists two groups of values:
Next Refresh and Until Next carry values only while the status is Scheduled; otherwise they show -. While Scheduled, Until Next counts down and the panel reloads when the countdown reaches zero. The panel also reloads by itself every five seconds. A missing value shows -.
Dates show as month, day and 24-hour time. Durations appear as ms, s or m, sizes in B, KB, MB, GB or TB, and row counts with thousands separators.
While the panel loads it reads Loading view refresh data.... A view with no refresh record yet reads No view refresh data available.
When the last refresh ended with an error, an Error section below the values shows the message. Cancelled refreshes are not reported as errors. After you cancel a refresh, a Cancelled badge appears next to the heading for a few seconds.
Truncate clears the rows the view stores. The view itself stays.
When it finishes, Table truncated successfully appears. If it fails, the toast reads Failed to truncate table, or the message the server sends.
Truncate is hidden while a refresh is running. Wait for the refresh to finish, or cancel it, and the button comes back.
A truncate cannot be undone: the rows the view held are gone. The view keeps its definition, and its next refresh loads rows again.
For the full list, see Warehouse permissions and row-level security.
The view is saved but not yet in the warehouse. Deploy the view first; until then the tab loads no statistics and no refresh data. Views covers the deploy step.
Yes. The numbers reload on their own when a refresh runs. At any other time, click Refresh to reload them.
It runs a refresh straight away and leaves the plan as it is. It appears while the status is Scheduled.
Stop Schedule pauses the planned refreshes; Start Schedule turns them back on. Cancel Refresh stops the refresh that is running right now.
You cancelled a refresh. The badge sits next to Refresh Settings for a few seconds and then goes; a cancelled refresh is not an error.
Truncate is hidden while a refresh is running. Wait for the refresh to finish, or click Cancel Refresh, and the button comes back.
No. Truncate clears the view's stored rows; the view and its definition stay. When the view refreshes again, it loads rows again.
Below the panel values, an Error section shows the message from the last refresh that ended with an error. A cancelled refresh is not reported there.
Controlling a refresh needs Add/Modify Warehouse Objects. A refused action starts with Access denied. Required permission(s): and names what to grant; Warehouse permissions and row-level security has the details.