Why does CALENDAR function throw 'start or end date cannot be blank' only in Power BI Desktop with I

[manoj_0911]

Why does CALENDAR function throw 'start or end date cannot be blank' only in Power BI Desktop with Incremental Refresh?

Hello Power BI Community,

I'm implementing Incremental Refresh for my report, and encountering the following issues only in Power BI Desktop, not in Power BI Service:

---

❗ Error 1:

The start date or end date in Calendar function cannot be a blank value.

My DAX is:

Date = 
CALENDAR(
    DATE(2025, 6, 20),
    MAXX('EOD_REPORT_V', 'EOD_REPORT_V'[DATE] - TIME(7, 0, 0))  // UTC to PDT conversion
)

🔍 What I know:

• This error happens only in Desktop, not in Service.

• The 'EOD_REPORT_V'[DATE] field is datetime and populated in actual data.

• I assume Power BI Desktop applies RangeStart (06/20/2025) /RangeEnd (06/21/2025) filters during preview, and the table might appear empty.

---

❗ Error 2:

This expression refers to a Partition object named 'Date[Date]', which has an error.

From this table:

DatePeriods = 
UNION(
    ADDCOLUMNS(
        FILTER(CALENDAR(MIN('Date'[Date]), MAX('Date'[Date])), [Date] = TODAY()),
        "Type", "Today", "Sort", 1
    ),
    ADDCOLUMNS(
        FILTER(CALENDAR(MIN('Date'[Date]), MAX('Date'[Date])), [Date] = TODAY() - 1),
        "Type", "Yesterday", "Sort", 2
    ),
    ADDCOLUMNS(
        CALENDAR(MIN('Date'[Date]), MAX('Date'[Date])),
        "Type", "Custom", "Sort", 3
    )
)

This error seems related to referencing the 'Date' table too early during partition refresh.

---

📌 My questions:

1. Why does MAXX() return BLANK() in Power BI Desktop during development, but works fine after publishing to the Service?

2. Is it recommended to wrap such expressions with COALESCE(..., fallbackDate) when using CALENDAR with incremental refresh?

3. What's the best practice to avoid partitioning-related errors like the one in DatePeriods when referencing calculated tables?

I want to make sure this logic is robust and won’t break in production during future refresh cycles.

Thanks in advance for your help!

[v-echaithra]

Hi @manoj_0911 ,

May I ask if you have gotten this issue resolved?

If it is solved, please mark the helpful reply or share your solution and accept it as solution, it will be helpful for other members of the community who have similar problems as yours to solve it faster.

Regards,
Chaithra.

[v-echaithra]

Hi @manoj_0911 ,

We wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?
If our response addressed, please mark it as Accept as solution and click Yes if you found it helpful.

Regards,
Chaithra.

[v-echaithra]

Hi @manoj_0911 ,

Calculated tables cannot read slicer values since they are only computed when the data is loaded, not whenever you interact with a slicer. Therefore, your End_Date measure returns a blank since it isn't filtered by the slicer.

You can use measures within any calculated tables but they won't interact with any dynamic slicers or filters. Calculated tables in your data model are static once the model is loaded. You can, however, use temporary/dynamic calculated tables within a measure so long as the measure still returns a single value at the end.

It seems that you're making some grammatical errors, or trying to put a table inside the table...and this is a wrong syntax. You're referencing the 'Date' table (a calculated table) inside another calculated table (DatePeriods) — but during Desktop preview or schema processing, 'Date' might not be fully evaluated yet, especially during partition setup.

it's recommended to wrap start/end expressions with COALESCE() to avoid blank inputs.
MIN('Date'[Date]) fails because 'Date' doesn’t yet exist in full context during partitioning. Hence, use hardcoded or parameterized values instead of dynamic min/max date.

If this helped, please mark it as the solution so others can benefit too. And if you found it useful, kudos are always appreciated.

Thanks,
Chaithra E.

[lbendlin · Accepted solution]

1. Always use UTC. Always.  If you want, use COALESCE to substitute for BLANK()

2. see 1

3. see 1

Note that Power BI has no idea what a timezone is. It's up to the Power BI service to negotiate that with the user's browser.