Forum Discussion
DAX Info Functions Against Published Datasets
Hello,
As part of a Power Automate Flow that we setup months ago, we were using the new DAX Info functions to pull metadata regarding partitions and expressions. These queries have been working without issue until this past weekend. Here is an example of a simple DAX query that would return information about the queries loaded to the data model:
For the last couple of days, these have failed to execute with a generic error stating "Failed to execute the DAX query" and an Analysis Services Error Code of 3239575574. We have a lot of other Flows that run DAX queries against a dataset in this manner, and those have had no issues.
Any ideas what may be preventing these queries from executing properly?
I've had an open support request with MS since this started happening back in January. I recently started up the conversation again, and I just heard from their engineers this morning that they fixed the issue. I checked our Power Automate Flow has been failing on that step since January, and it did successfully run this morning. It seems that the issue should be resolved now.
56 Replies
I have an incident open with Microsoft, and I'll be meeting with one of their PBI engineers early next week. I'll post back here once we get more info.
Our DAX queries that utilize those INFO functions are still failing. This has been broken for over 5 months now. Are we any closer to a resolution today?
Got an answer today:
I hope you're doing well. I apologize for the delay in getting back to you. I wanted to inform you that I checked internally and received an update that the feature code has been successfully deployed into production, and our team is currently conducting thorough testing. Once the testing is completed, they will proceed to enable the feature switch.
I truly appreciate your patience and understanding on this matter. I will keep you informed and provide an ETA as soon as possible after receiving the update from the team. Thank you very much for your cooperation.
Hi, I will send them a mail today.
Does anybody know if there has been any resolution to this please?
It's been a few months and we are still having to try working around this.
What is the current status on a fix for this? Any ETA?
Seems like there wont be any solution anytime soon. I switched over to using the Analysis Backend and querying every single dataset manually. You get the same output atleast for datasources using the following query
SELECT * FROM $SYSTEM.TMSCHEMA_PARTITIONS
I can confirm I got the exact same issue. We use this INFO.PARTITIONS for reporting and impact analysis when we change and/or modify data sources. Was quite practical, but since the beginning of this week it returns a 400 bad request. . Other DAX queries accessing dataset tables work fine though.
Same problem here.
We are a startup building iOS application to be able to integrate data from Power BI using REST API.
We built this application and deployed to users.
Till last week this was working fine.
This is unacceptable to hear from my last Support call, that Product team does not know if it will be fix and by when.
We have users completly blocked because this API calls now retrun 400 Bad Request.
We need a work around, we are OK to use any other API if needed but we need to be able to get metadata from a Semantic Model with executing INFO.VIEW.COLUMNS( ) and INFO.VIEW.MEASURES( ).
Especialy this is working fine in DAX Studio.
I hope to get a better answer rapidly.
If anybody is interested I got another answer today.
Greetings for the day! I hope you’re having a wonderful day. We understand the difficulty you're facing with the situation where the feature was previously working and has suddenly stopped. It must be incredibly challenging for you, and we sincerely apologize for the inconvenience.
The product team mentioned that they cannot revert the changes since it will introduce a security problem. We are currently checking if there is any ETA for a fix. As soon as we get any information from them, we will promptly update you.
We genuinely appreciate your cooperation and support during this time. Thank you once again for your patience and understanding.
I've hit the very same problem. We had just put a production Python data ingestion in place to extract the queryDefinition from all datasets and ingest into Snowflake. From that we could extract Snowflake database/schema/model, native queries, Sharepoint etc. That meant we could get a full overview in data sources used in our publish PBI datasets.
Now without warning that functionality does not work.
I can do some of it on a local script (on Windows with ADOMD) or per dataset with DAX Studio. However it does leave our recent production implementation redundant until we have a viable alternative. Surely it shouldn't be so difficult to get this partition data!
I sent a message to Microsoft today and this is the answer I got. In my opinion, it's BS, proably are they waiting for the FabCon in Las Vegas to end before they dare to push a new version (which was yesterday I think).
Hello Niclas,
Greetings for the day!
I sincerely apologize for the inconvenience you've been experiencing. After consulting with our internal team, I got to know that the deployment failed due to an unexpected outage. We deeply regret any disruption this has caused you.
The good news is that our team is actively working on resolving the issue, and we anticipate that the fix will be implemented by the end of this week. I kindly ask you to check the behavior once the fix is deployed, and let us know if the issue persists.
Thank you for your understanding and patience.
I've had an open support request with MS since this started happening back in January. I recently started up the conversation again, and I just heard from their engineers this morning that they fixed the issue. I checked our Power Automate Flow has been failing on that step since January, and it did successfully run this morning. It seems that the issue should be resolved now.
Hi, This is not working on my end. Could you confirm you can still run the INFO.PARTITIONS() query through the API? rjhale
We're using Power Automate to run these queries, and yes, that does seem to be working as expected as of this morning. This same call was failing between January and July.
Same Problem here - we had a DAX query with InfoFunctions to get the last refresh of a Table running for Month running via REST API on Pruduction and today it started failing
I have the same issue too. Does anyone has any clue why and what to do? Is it a bug or a deprecation?
Same problem too
Hello rjhale
It looks like the issue with DAX Info functions failing to execute against published datasets is caused by a bug introduced in the November 2024 update (version 2.138.782.0) of Power BI Desktop. This bug specifically affects the execution of DAX Info functions like CALENDARAUTO when opening certain files.
https://www.reddit.com/r/PowerBI/comments/1gqtl7m/nov_update_20241111_throws_unable_to_execute_dax/
To resolve this issue:
1. Revert to the October 2024 build (2.137.1102.0) of Power BI Desktop, which opens affected files without complications.
2. Wait for the January 2025 update of Power BI Desktop (Version: 2.139.1678.0), which has fixed this issue.
3. If using the latest version, modify your DAX code to avoid using CALENDARAUTO and instead use alternative methods for creating date tables.hopefully this resolves your query.
Please accept this solution and give kudos, if you find this helpful
I don't think this is the same issue as outlined in that Reddit thread. The issue I described went from successfullly executing on 50+ datasets to failing on those same datasets sometime between last Friday and Monday morning. These would have been datasets published with older version of Power BI desktop and possibly a few since the November release.
Just to be sure though, I did update to the January release, republished one of the datasets, and retried the DAX query: EVALUATE SELECTCOLUMNS(INFO.PARTITIONS(), [QueryDefinition]). It still fails with the same error message.
My suspicion is that something changed with the analysis service engine or maybe a new security policy.
