Dependency check does not look at M expression, e.g. incremental refresh

[waltheed]

Description

The Dependency check does not seem to look at M expression to see if a column is used. In My case it was the incremental refresh expression ike "... dtCreated > RangeStart ..." etc. QuiteDangerous if you throw away that column. I would expect that TE protects you from making that mistake.

Tabular Editor 3 Version

3.25.5

Screenshots

No response

Steps to Reproduce

No response

Expected behavior

No response

Crash Report

No response

Windows Version

No response

[mlonsk]

Hi @waltheed
I am a bit unsure what you mean by the "dependency check", could you clarify?
In any case, a column does not have to be in the semantic model to be used in an M expression, so it is safe to remove the column from the model even if the incremental refresh expression refers to that column.

[waltheed]

Hi Morten, Thanks for your quick reply. This is what I mean: * If you right-click an item in the TOM tree, you can choose "Show Dependencies". It is not shown there. * If you delete a column that is used in the model somewhere you receive a message, like "This object is referenced by one or more other objects through DAX expressions. Deleting it will cause dependent objects to stop functioning correctly. ". But that message is not shown in case of a column that is used in an M expression e.g. for Incremental refresh. But that makes sense if this is not an issue, as you suggest in your answer. I did not know that, and I find it a bit strange actually, but I'll try it and will be very happy if it does not, because these are usually expensive unique datetime columns. Thanks! Best regards, Edgar Walther BI Consultant + 31 6 3449 2516 [Edgar Walther] [ITsmart Logo]<https://itsmart.nl>

…

________________________________ From: Morten Lønskov ***@***.***> Sent: Tuesday, March 24, 2026 21:54 To: TabularEditor/TabularEditor3 ***@***.***> Cc: Edgar Walther (ITsmart) ***@***.***>; Mention ***@***.***> Subject: Re: [TabularEditor/TabularEditor3] Dependency check does not look at M expression, e.g. incremental refresh (Issue #1553) [https://avatars.githubusercontent.com/u/11939114?s=20&v=4]mlonsk left a comment (TabularEditor/TabularEditor3#1553)<#1553 (comment)> Hi @waltheed<https://github.com/waltheed> I am a bit unsure what you mean by the "dependency check", could you clarify? In any case, a column does not have to be in the semantic model to be used in an M expression, so it is safe to remove the column from the model even if the incremental refresh expression refers to that column. — Reply to this email directly, view it on GitHub<#1553?email_source=notifications&email_token=AD47ZZZMES6MFYDWXOJ3MQT4SLYZVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJSGEZDSNZZHEZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4121297992>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD47ZZ7HK3DTSUEINMMHGZ34SLYZVAVCNFSM6AAAAACW5VUZAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMRRGI4TOOJZGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[greggyb]

Just a bit of additional nuance here:

The TOM column in the TOM Explorer depends on the M expression in the partition for the table the column belongs to. That dependency is one way. The partition definition does not depend on the TOM column.

Consider the situation where a source system gains a new column, and refreshes of the semantic model continue. This is a situation where the result of the M expression yields more columns than the TOM table holds.

Here is a screenshot showing a situation in which the M partition of a table holds 2 columns, but you can see in the TOM Explorer that the table has only one column. In the leadup to this screenshot, I:

1. Created the table
2. Wrote the expression for the partition (as you see it)
3. Updated the table schema (at this point it showed two columns in the TOM Explorer)
4. Deleted 'm>tom'[col2] (at this point the TOM Explorer showed as you see it in the screenshot)
5. Performed a full refresh of the table, 'm>tom'
6. Opened up a data preview of the table, 'm>tom'
7. initiated a schema update (this is what you see in the screenshot; I have not yet applied it)

This shows a model where the TOM table has been refreshed with a schema that is a subset of the M expression in its partition definition. This is a totally valid state to be in, and there is nothing wrong with it.

The opposite situation is not valid. If you have a TOM Column which does not align to any source column in the partition definition, then that is invalid.

[waltheed]

This makes it very clear, Thanks Greg!