Forum Discussion
Impactful IndividualDetect Data Changes - Incremental refresh
I am using below incremental refresh setting . it is giving me correct results after first refresh. The "modifieddate" is selected as "Detect Data Change"
I then changed the modified date of id 25 from 25th Oct 2026 to 26th Oct 2026, when i refresh again it still shows me the same result after second refresh as well , it should show me 26th Oct for ID =25, why Power BI is still showing old date 25th October instead of 26th Oct
Results after First refresh ( Results are same for second refresh as well)
Hi powerbiexpert22,
This comes down to how Detect data changes works. It doesn't look at single rows. For each partition inside the refresh window, Power BI stores the highest modifieddate it saw. On the next refresh it reprocesses that partition only if the new highest value is later than the stored one.
So two things can hide your edit. If ID 25 sits in a partition where another row already has a later modifieddate, the highest value didn't change and the partition is skipped. And partitions are split by the RangeStart/RangeEnd column (for example the created or order date), not by modifieddate. If ID 25's date falls in the archived part of the policy, it is never refreshed incrementally at all.
Also note that Desktop doesn't apply incremental refresh. This behaviour only shows after publishing to the Service.
To confirm, connect to the XMLA endpoint with SSMS or Tabular Editor and look at the partition that holds ID 25. To force the change in, refresh that one partition, or widen the refresh window for a run. If old rows get edited regularly, a refresh window long enough to cover your usual edits is the cleaner fix.
2 Replies
- LumericVisuals
Resolver I
Hi powerbiexpert22,
This comes down to how Detect data changes works. It doesn't look at single rows. For each partition inside the refresh window, Power BI stores the highest modifieddate it saw. On the next refresh it reprocesses that partition only if the new highest value is later than the stored one.
So two things can hide your edit. If ID 25 sits in a partition where another row already has a later modifieddate, the highest value didn't change and the partition is skipped. And partitions are split by the RangeStart/RangeEnd column (for example the created or order date), not by modifieddate. If ID 25's date falls in the archived part of the policy, it is never refreshed incrementally at all.
Also note that Desktop doesn't apply incremental refresh. This behaviour only shows after publishing to the Service.
To confirm, connect to the XMLA endpoint with SSMS or Tabular Editor and look at the partition that holds ID 25. To force the change in, refresh that one partition, or widen the refresh window for a run. If old rows get edited regularly, a refresh window long enough to cover your usual edits is the cleaner fix.
jubinsoniSkilled Sharer
Hi powerbiexpert22,
Detect data changes doesn't look at individual rows. For each partition inside the refresh window, the service stores the MAX of modifieddate, and on the next refresh it only reprocesses that partition if the new MAX is higher. That gives three common reasons the change to ID 25 is ignored.
1. The max didn't move. If another row in the same partition already has a modifieddate of 26 Oct or later, the partition's MAX is unchanged and the partition is skipped. Check it at the source:
-- which period does ID 25 belong to, and what's the max per period? SELECT CAST(OrderDate AS date) AS PartitionDay, -- your RangeStart/RangeEnd column MAX(modifieddate) AS MaxModified, SUM(CASE WHEN id = 25 THEN 1 ELSE 0 END) AS HasId25 FROM dbo.YourTable GROUP BY CAST(OrderDate AS date) ORDER BY PartitionDay DESC;2. The row's partition is outside the refresh window. Partitioning uses the RangeStart/RangeEnd column, not modifieddate. If ID 25's partition date is older than "refresh rows in the last N days", it's never checked, whatever its modifieddate is.
3. You're testing in Desktop. The policy (and detect data changes) only applies after publishing; the refresh in Desktop just reloads the RangeStart/RangeEnd slice. Test the second refresh in the service.
For testing, the cleanest check is a real edit in the service: bump modifieddate for ID 25 to the current timestamp, so it's guaranteed to be the partition's new max. Then refresh in the service and look at that partition's RefreshedTime with INFO.PARTITIONS, as in your other thread.
So my overall approach would be:
Confirm testing in the service (not Desktop) ID 25 partition date inside the refresh window? no -> it will never be polled MAX(modifieddate) of that partition increased? no -> partition skipped by design Set modifieddate = now -> service refresh -> check partition RefreshedTimeAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.