Refresh and Run Schedules

Help ID: query-runner.run-schedule

Right-click the application's shared refresh icon to configure it. The help icon beside the Auto-refresh heading opens this topic. Set an interval using the custom value and Seconds / Minutes / Hours combo. Expand Run schedule for optional restrictions.

In Pilot, the icon is hidden while auto refresh is off: right-click the tab name and check Auto refresh to enable it and reveal the icon. Then right-click that icon to configure it, just like grids, the dashboard, and the calendar. The tab menu only toggles auto refresh; it neither opens configuration nor duplicates its fields. Turning auto refresh off hides the tab icon again. Apply schedule applies advanced options; dismissing the popup without applying discards advanced edits. The basic auto-refresh checkbox, custom interval, and background option apply immediately.

Controls

• Enable auto-refresh turns automatic refresh on or off. In Pilot it controls the selected tab's existing timer.
• Every is a custom value with a Seconds / Minutes / Hours combo. Enter 30 Seconds, 5 Minutes, or 1 Hours, for example. The combo applies the chosen unit to the entered number. Existing intervals reopen using the largest exact whole unit: 3600 saved seconds displays as 1 Hours, and 90 seconds displays as 90 Seconds. The underlying saved value remains seconds, so existing settings do not change merely by opening the popup. Fractional values are supported when they resolve to whole seconds, such as 0.5 Hours. Invalid values show an error and leave the last valid interval unchanged. Pilot accepts one second through seven days; ordinary shared refresh controls have a five-second minimum and the same seven-day maximum.
• Use run schedule enables the additional limits. Leave it off for ordinary refresh behavior.
• Active days and hours restrict automatic starts. Times use the workstation's local time zone, shown on the form. Selected weekdays identify when a window starts. For example, Monday 20:00–06:00 includes Tuesday morning. Equal start/end times mean 24 hours from the selected starting day.
• Maximum runtime specifies a per-execution limit, not a total budget across all runs. Uncheck it for unlimited duration. Runtime/cancellation controls appear only when the host provides cancellable execution; Pilot does, while ordinary inventory refreshes only expose start-window and final-cutoff limits.
• End date/time is an optional final cutoff for the whole schedule. No new automatic execution starts at or after it.
• Cancel running SQL at limits explicitly permits cancellation requests at maximum runtime, active-hours end, or final cutoff. It is off by default. Without it, active hours and the final cutoff prevent new starts, but running SQL can finish; the maximum-runtime setting does not interrupt it.

For scheduled Pilot execution, Every is the idle wait after the previous run finishes, including cancellation cleanup. It is not the maximum runtime and it does not request cancellation.

What the Cancellation Checkbox Means

Unchecked means the maximum-runtime setting is ignored entirely. It does not stop the query, and it does not prevent a later run merely because the previous run exceeded that duration. Active hours and the optional end date/time still prevent new automatic starts outside their allowed range.

Checked means Pilot requests cancellation at the earliest enabled limit: maximum runtime, the end of the active-hours window, or the final end date/time. Pilot waits for the execution task to finish cleaning up, then waits the configured interval before another eligible run.

The scenarios below assume the first execution starts at the stated time and no independent connection timeout or execution-policy restriction interrupts it first.

Scenario 1: Let a Long Query Finish

Settings: Every 30 Seconds, active hours 20:00 to 06:00, maximum runtime 60 minutes, cancellation unchecked.

This is useful when the allowed window controls when work may start, but an in-progress report should not be interrupted. The 60-minute setting is not an overall scheduling cutoff.

Scenario 2: Limit Each Execution to One Hour

Use the same settings as Scenario 1, but check Cancel running SQL at limits.

This does not mean one hour of work followed by one hour of rest: the wait is still only 30 seconds.

Scenario 3: One Hour Working, One Hour Resting

Set Every to 1 with Hours selected, set Maximum runtime to 60 minutes, and check Cancel running SQL at limits. Enable the desired active days/hours and optional final cutoff.

If an execution starts at 20:00, Pilot requests cancellation at 21:00. Once that execution finishes stopping, Pilot waits a full hour before starting again. If cleanup finishes at 21:02, the next start is no earlier than 22:02 and must still be inside the allowed window. If the script finishes early at 20:25, the one-hour wait starts then, so the next eligible start is 21:25.

This is repeated execution of the script, not pausing and resuming the same SQL session. Ensure a maintenance script is safe to rerun.

Scenario 4: Finish Scheduling at a Fixed Date/Time

Enable End date/time and set it to the desired cutoff, for example tomorrow at 22:00.

• Cancellation unchecked: no new automatic executions start at or after 22:00, but a running execution can finish afterward.
• Cancellation checked: no new automatic executions start at or after 22:00, and Pilot requests cancellation of the one still running at that time.

An earlier runtime or active-hours limit wins when cancellation is enabled.

Scenario 5: Ordinary Five-Minute Refresh

For an ordinary dashboard or grid refresh, enter 5 Minutes and leave Use run schedule off. No active-hours, runtime, or final-cutoff restrictions are applied. Runtime/cancellation fields are only shown for hosts that support cancellable execution, such as Pilot.

Execution Behavior

The first automatic execution waits for the configured idle interval and the next allowed window. Runs never overlap within a tab, including while an execution is preparing or stopping. Missed executions during sleep or while the application is closed are not replayed in a burst. The next eligible run is evaluated when Pilot is active again.

The timer requests cancellation using the same cancellation token as the Cancel command. A request is not a guarantee of immediate server-side termination. Pilot waits for its execution task to return before starting the idle delay or allowing another automatic execution. Do not use this schedule as an emergency SQL termination mechanism.

Closing a tab prevents future automatic runs from it. An already-running scheduled execution retains its stop deadline until cleanup completes; closing its tab does not silently remove the runtime limit.

Manual Run remains available outside the automatic schedule and is not cancelled by these limits. Turning automatic runs off prevents future starts; it does not immediately cancel an already-running command. A scheduled run that was already started still observes its configured cancellation boundaries. Connection command timeouts and execution-policy gates still apply independently. Cancellation does not invoke a success follow-up script.

The shared refresh icon displays the configured interval while auto refresh is enabled. Schedule edits apply to the next timer evaluation, including edits to a running scheduled execution's limits. Detailed execution and scheduling state is included in diagnostics.

Recovery and Diagnostics

Pilot options are saved with tabs included in the recovery session and restore with those tabs. Older sessions without schedule options retain ordinary refresh behavior. Other refresh controls retain advanced options for their control lifetime unless their host binds RunSchedule to persistent settings. Scheduling runs only while the GUI is open; this is not a SQL Agent or Windows Task Scheduler job.

Support bundles include schedule options, next start, start/stop boundaries, and cancellation state, but not SQL text or connection secrets. A cancellation request also records a schedule support event.

Daylight-saving skipped times advance to the first valid minute. Ambiguous times use the local time zone's standard-time interpretation. A selected overnight window belongs to its starting weekday.

Related: Query Pilot, Feature list.

Documentation revision: 8EDE46421095F47F