Starting December 3, join live sessions with database experts and the Microsoft product team to learn just how easy it is to get started
Learn moreGet certified in Microsoft Fabric—for free! For a limited time, get a free DP-600 exam voucher to use by the end of 2024. Register now
I made a change to an existing report, which is saved in SharePoint and is connected to a Power BI report in the workspace. I removed a 'date' column and added a new column called 'report_date' (they both had different formatting.)
Since making this change I get the following error in the PBI workspace which I can see is due to the column I removed. Is there any way to resolve this that doesn't involve reuploading the report? It's currently live and shared with multiple people so really hoping to avoid this. I've had this issue a few times previously and the only solution has been to reupload.
Last refresh failed: 09/01/2024, 14:32:51 There was an error when processing the data in the dataset.Hide details Data source error: The 'date' column does not exist in the rowset. Table: XXXXXX. Cluster URI: WABI-UK-SOUTH-C-PRIMARY-redirect.analysis.windows.net Activity ID: abf0ea51-4bb9-4a4a-aaff-48a6239058d5 Request ID: b22ca1af-282f-7603-7bc1-4f22633e9601 Time: 2024-01-09 14:32:51Z
Solved! Go to Solution.
This will be considered a model change. You can either download the report and open it in desktop, or if you are an admin in the workspace, you can enable the ability to edit data models in the service. Workspace Settings > Power BI > General > Data Model Settings
I don't understand wy there are restrictions on large transfers. That seems a bit arbitrary. If that is the case you should move to splitting this report to a thin report that is just a few MB in size pointing to the model in the service you manage by Tabular Editor. You make all changes in the service directly and publish a revised report only. That link would never change.
You could also split to a thin report and model and do this:
In this case, the report link never changes so your users dont know there has been a change.
But if you continue the current path of a new semantic model and report with each publication, you will have to give a new link every time, a major hassle.
DAX is for Analysis. Power Query is for Data Modeling
Proud to be a Super User!
MCSA: BI ReportingThis will be considered a model change. You can either download the report and open it in desktop, or if you are an admin in the workspace, you can enable the ability to edit data models in the service. Workspace Settings > Power BI > General > Data Model Settings
Thanks for your response on this, I tried to change the setting you've highlighted as I am an admin the workspace but it's greyed out. I'll look in to the possiblity of having this enabled for future
Ah yes, you will have to have whoever your Tenant Admin is turn it on from their Admin Portal. Thank you for the kudos
The report isn't shared through app, it has been shared using the link to the report. When I reupload I need to share that link with anyone who had access to the previous version. Unless there is something simpler that i'm missing?
Is it in a workspace? It should not require a new link, it should just work. Is it in "My workspace?" That still shouldn't require a new link, unless you are sharing it via Publish to the Web, which has no security but it does require a new link with each republish.
DAX is for Analysis. Power Query is for Data Modeling
Proud to be a Super User!
MCSA: BI ReportingIt's in a private workspace that my immediate team have access to - I then grant access and share the link for this specific report to other people or groups so they only have access to this one report.
I should also add that I can't 'publish' this report through Power BI desktop as we have internal restrctions on large file transfers. I have to upload through sharepoint and refresh the report in PBI service so when I reupload, it uploads as a brand new version rather than replacing the one already there.
I don't understand wy there are restrictions on large transfers. That seems a bit arbitrary. If that is the case you should move to splitting this report to a thin report that is just a few MB in size pointing to the model in the service you manage by Tabular Editor. You make all changes in the service directly and publish a revised report only. That link would never change.
You could also split to a thin report and model and do this:
In this case, the report link never changes so your users dont know there has been a change.
But if you continue the current path of a new semantic model and report with each publication, you will have to give a new link every time, a major hassle.
DAX is for Analysis. Power Query is for Data Modeling
Proud to be a Super User!
MCSA: BI ReportingThanks for your help with this and time coming up with a solution. From looking at the possible workarounds, I think the best option going forward is to getthis report on an app. We have a few reports which could be impacted this by this so seems the most straightforward option!
You have to make the change in the service. You can either republish the report, or you can edit the model directly in the service using Tabular Editor if it is in a Premium workspace - Premium Capacity or Premium Per User. You must also have the XMLA Endpoint turned on for read/write access, and know how once you have made the schema change to fully refresh that table as the column will be empty upon creation.
Unless you are well versed in this, I think reuploading is the best bet. If this is in a workspace and shared via an app, the end users will never know. It will just work.
What is your aversion to republishing? How have you shared this?
DAX is for Analysis. Power Query is for Data Modeling
Proud to be a Super User!
MCSA: BI ReportingStarting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early Bird pricing ends December 9th.
User | Count |
---|---|
34 | |
30 | |
19 | |
12 | |
8 |
User | Count |
---|---|
51 | |
36 | |
29 | |
14 | |
12 |