Forum Discussion
Filtering on DateTime.LocalNow()
I am using below M code in the power query to filter the data in my query. I was hoping the DateTime.LocalNow() will be changing in the WHERE clause of the sql generated whenever i refresh the report but it seems to be static timestamp no matter how many times i refresh the report. Is this expected behaviour ? The source is fabric warehouse connected through sql end point.
#"Filtered Rows" = Table.SelectRows(#"Changed Type", each [Date_Time] < DateTime.LocalNow())
in
#"Filtered Rows"
Hi Puneethg78,
Thanks for reaching out to the Microsoft fabric community forum.
Based on what you've described and the SQL captured in Profiler, it looks like DateTime.LocalNow() is being evaluated on the client side (within Power BI), and its value is getting embedded as a static literal in the folded SQL query. That’s why the timestamp doesn’t change across refreshes, and the warehouse ends up returning cached results.
Even though the query folds, not all M functions translate to equivalent SQL functions. In this case, DateTime.LocalNow() doesn’t get translated into something like GETDATE() at the SQL level, it gets evaluated at the time the query is generated, and the resulting timestamp is pushed to SQL as a fixed value.
If your goal is to force a fresh timestamp on every query execution (e.g., for stress testing), we’d recommend moving the date filtering logic into a SQL view or using a native SQL query with GETDATE() directly, this ensures the timestamp is evaluated inside the warehouse each time, and avoids hitting the cache.
I would also take a moment to thank lbendlin, for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
If I misunderstand your needs or you still have problems on it, please feel free to let us know.
Best Regards,
Hammad.
Community Support TeamIf this post helps then please mark it as a solution, so that other members find it more quickly.
Thank you.
6 Replies
Have you confirmed that that query folds?
Yes, I can see the query folding happening. However, while refreshing the report either in desktop or service the value doesn't change while I check the sql from SQL Profiler. Because of this, the query is fetching the data from Fabric Warehouse Cache and impacting my stress test results. Wondering if there is any other way to avoid hitting the cache in the warehouse while doing stress test.
select [_].[Date] as [Date],
[_].[WEEKDAY_NM] as [WEEKDAY_NM],
[_].[DAY_NUM] as [DAY_NUM],
[_].[LM_DT] as [LM_DT],
[_].[LQ_DT] as [LQ_DT],
[_].[LY_DT] as [LY_DT],
[_].[Month_Start_Date] as [Month_Start_Date],
[_].[Quarter_Start_Date] as [Quarter_Start_Date],
[_].[Year] as [Year],
[_].[ONGNG_DAY_TXT] as [ONGNG_DAY_TXT],
[_].[ONGNG_MNTH_TXT] as [ONGNG_MNTH_TXT],
[_].[Date] as [Date - Copy]
from [dbo].[TBIC_DATE] as [_]
) as [_]
) as [_]
where [_].[t0_0] < convert(datetime2, '2025-04-19 19:36:57.8415026')
Hi Puneethg78,
Thanks for reaching out to the Microsoft fabric community forum.
Based on what you've described and the SQL captured in Profiler, it looks like DateTime.LocalNow() is being evaluated on the client side (within Power BI), and its value is getting embedded as a static literal in the folded SQL query. That’s why the timestamp doesn’t change across refreshes, and the warehouse ends up returning cached results.
Even though the query folds, not all M functions translate to equivalent SQL functions. In this case, DateTime.LocalNow() doesn’t get translated into something like GETDATE() at the SQL level, it gets evaluated at the time the query is generated, and the resulting timestamp is pushed to SQL as a fixed value.
If your goal is to force a fresh timestamp on every query execution (e.g., for stress testing), we’d recommend moving the date filtering logic into a SQL view or using a native SQL query with GETDATE() directly, this ensures the timestamp is evaluated inside the warehouse each time, and avoids hitting the cache.
I would also take a moment to thank lbendlin, for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
If I misunderstand your needs or you still have problems on it, please feel free to let us know.
Best Regards,
Hammad.
Community Support TeamIf this post helps then please mark it as a solution, so that other members find it more quickly.
Thank you.
Hi Puneethg78,
As we haven’t heard back from you, so just following up to our previous message. I'd like to confirm if you've successfully resolved this issue or if you need further help.
If yes, you are welcome to share your workaround and mark it as a solution so that other users can benefit as well. If you find a reply particularly helpful to you, you can also mark it as a solution.
If you still have any questions or need more support, please feel free to let us know. We are more than happy to continue to help you.
Thank you for your patience and look forward to hearing from you.Hi Puneethg78,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. If my response has addressed your query, please accept it as a solution so that other community members can find it easily.
Thank you.
