Skip to content

fix(view): sp_refreshview when a view rebuild is skipped - #821

Merged
axellpadilla merged 2 commits into
dbt-msft:masterfrom
Benjamin-Knight:fix/view-skip-refreshview
Aug 19, 2026
Merged

fix(view): sp_refreshview when a view rebuild is skipped#821
axellpadilla merged 2 commits into
dbt-msft:masterfrom
Benjamin-Knight:fix/view-skip-refreshview

Conversation

@Benjamin-Knight

Copy link
Copy Markdown
Collaborator

resolves #820

A skipped view rebuild (unchanged compiled SQL) left select * views serving stale, shifted columns whenever a referenced table's shape changed, since SQL Server caches select * expansion at CREATE/ALTER time and the skip never reissues that statement. Run sp_refreshview on the skip path instead of a no-op so the cached column metadata stays in sync without forcing a real rebuild.

A skipped view rebuild (unchanged compiled SQL) left select * views
serving stale, shifted columns whenever a referenced table's shape
changed, since SQL Server caches select * expansion at CREATE/ALTER
time and the skip never reissues that statement. Run sp_refreshview
on the skip path instead of a no-op so the cached column metadata
stays in sync without forcing a real rebuild.

Verified by executing the generated declare/exec statement directly
against a live warehouse view.
The unchanged-view no-op test asserted sys.objects.modify_date was
unchanged across a rerun. That was a valid stand-in for "no rebuild"
only while the skip path emitted a literal no-op; sp_refreshview bumps
modify_date exactly as an ALTER does, so the assertion now fails on a
correctly skipped run. Assert what the test was written to guard
instead: the run emits sp_refreshview, emits no CREATE OR ALTER VIEW,
and leaves the stored definition byte-identical.

Add the coverage the refresh itself was missing: a view selecting * from
a table created outside dbt, whose shape then changes, must report the
table's current columns after a run that skipped the CREATE.

Also give the refresh statement the model's database as a USE prefix.
sp_refreshview resolves its argument in the current database, so a
cross-database view model would have errored on an unresolvable name
where it previously executed a harmless no-op.
@axellpadilla
axellpadilla merged commit 427fd05 into dbt-msft:master Aug 19, 2026
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

view materialization silently serves stale columns after a skipped rebuild

2 participants