Forum Discussion
Helper IDisable "Include in report refresh" does not work
Memorable MemberHi powerlight1,
Echoing v-aatheeque and maruthisp: the Include in report refresh setting only controls whether a query is run during a refresh, and, as maruthisp notes, a query that other queries depend on may still be evaluated. Both replies suggest checking Query Dependencies, and that is the right first step. The part I would add is why unchecking the box does not make the message go away: the warning about a missing column is about the table definition the model has stored versus the shape the query returns when you close and apply, which is a separate step from refreshing data. So the setting alone may not be enough to freeze a table whose source has changed. I can't see your file, so treat the options below as ways to get to a frozen copy rather than a guaranteed fix.
What each setting does
| Setting or action | What it affects | What it does not do |
|---|---|---|
| Include in report refresh unchecked | The query is skipped during refresh | It does not stop a dependent query from evaluating the source, and it does not change the stored column definition |
| Close and Apply | Reconciles the query output with the model table | It can raise the missing-column warning even if refresh is off |
| Query Dependencies view | Shows what else references the table | Does not change anything by itself |
Ways to keep the old data and add the new table
| Option | How | Trade-off |
|---|---|---|
| Snapshot the old data into a static table | Export the old table from the report (for example with an export from a table visual) and load it as its own source, or paste it with Enter Data for small tables | The data is frozen for good and no longer depends on the changed source |
| Duplicate the query: one frozen, one live | Keep a copy of the old query for the legacy data and create a separate query for the new table version | Two tables to maintain, but each has a clear purpose |
| Make the old query tolerant of the missing column | Select the columns with MissingField.UseNull so the step does not fail when the source column is gone | Keeps the layout, but the data for the missing column becomes null on refresh |
A tolerant column selection looks like this:
let
Source = OldTable,
// keep the columns the report was built on; missing ones become null instead of an error
Keep = Table.SelectColumns(Source, {"Id", "Name", "OldMeasureColumn"}, MissingField.UseNull)
in
KeepIf the old data is the part that must never change, the snapshot is the safest of the three, because nothing in the file then depends on the source that was altered. Afterwards, load the latest version of the table as a separate query, and use relationships or a merge to connect the two where needed.
So my overall approach would be:
1. Check Query Dependencies for anything still referencing the old table
2. Freeze the old data as a static snapshot, separate from the source
3. Load the latest table version as its own query
4. Use MissingField.UseNull anywhere the old column list must be keptAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.