SSAS Tabular Model has been changed to AtScale model automatically

[gayatrisr]

I'm unable to use Power BI reports in service. I get the error - This report couldn't access the data source. Contact the author to have it fixed. I verified the data source and found out that the model has been changed for couple of reports from SSAS Tabular project to AtScale model. How do I fix this. Why has this happened. I can see that this change has happened to couple of reports that had new changes made to it. The older report which has not been published recently is still referring to the same model and is working fine. Please guide.

[Greg_Deckler · Accepted solution]

Posting the root cause and fix here. Please refer to this Issue. The fix has been confirmed with a customer.

SSAS Tabular Models converted to AtScale Automatic... - Microsoft Fabric Community

Root Cause

This issue was identified and fixed last year. We realized we were incorrectly classifying SSAS models as AtScale. The bug was in production for 1-2 months before being fixed and any live connected reports created during that time were being classified as AtScale. Up until AtScale integration was finished ~1-2mo ago, we were treating AtScale virtually the same as SSAS with no parameters added to the connection string - so no change in report behavior. Some of these reports could have been holding onto the AtScaleDatabaseLive connection type for the last year, and now after republishing, they're unfortunately catching the new WSID connection string parameter. This lines up with the the inability to reproduce the issue today and why new reports are working as normal, but the customer republishing existing reports causes the WSID property to appear and failure in gateway.

Fix

Saving the file as a .pbip (PBI Project) file, exposing the metadata for the connection and change it there (something you can't do in the PBI Desktop UI.)  Saving as a zip file, changing the Connection file there, and then resaving as PBIX just ends up as a corrupted file so that is not an available fix.

Update per @dato_Niall : When saving the PBIP file type, this exposes an extra folder (with the meta data @Greg_Deckler mentions) called [ReportName].Report where the PBIP file was saved. Within this folder is a file called 'definition'. This if opened in notepad is where the datasource can be edited. Once this is edited you can then save the report back to PBIX file and this fixes the issue.

[dato_Niall]

Hi Greg, this great! When you say change the meta data? Could you eloborate a little more? Is this in the additional files that are created upon saving? Is there a particular file name that holds this meta data for us to change?


Update: When saving the PBIP file type, this exposes an extra folder (with the meta data @Greg_Deckler mentions) called [ReportName].Report where the PBIP file was saved. Within this folder is a file called 'definition'. This if opened in notepad is where the datasource can be edited. Once this is edited you can then save the report back to PBIX file and this fixes the issue.

In our scenario, we didn't alter the PBIX in anyway. We made few measure edits as normal, saved the pbix and published it only to find that it saved itself with a Datasource connector of Atscale rather then SQL Analysis Services. We have no idea as to why but the fix identified by @Greg_Deckler saved us a heap of time recreating the report! Thank you!

[Greg_Deckler]

@dato_Niall Thanks, I should have included that detail in the answer. I have edited my post with the extra detail information you provided.

[jtrock]

This has been happening at our organization as well.

Reports that were created in Power BI Desktop using a Power BI semantic model selected from a workspace have been working as expected.

However, we have several reports that were created in Power BI Desktop in the past where we selected Analysis Services from the Get Data menu option, and then entered our SSAS Server and Data Model name to directly connection.  Every once in a while, one of these PBIX files, regardless of how far in the past they were made or modified, when opened in Power BI Desktop today, will now show an AtScale data source.

There are only two people at our organization that have access to these PBIX files, I'm one of them, and neither of us even know how to specify an AtScale data source.  Furthermore, the last modified date on the PBIX file was back in March 2024.  So, I believe this is something in a recent version of Power BI Desktop that is starting to misread the connection strings in old PBIX files.

I tried changing the .pbix extension to a .zip, unzipping the archive, and copying over the Connection data/file from a known good PBIX to an impacted PBIX and then re-zipping and changing the extension back to PBIX, but I no longer have any luck with this process like I did years back when trying to change out a data source fron Analysis Services to a workspace semantic model without having to rebuild the report in the past.

The only fix appears to be rebuilding the report.  Has there been any update to this issue?

[waltheed]

Hi all, same issue here. "Microsoft is working on that" Any new on this? 

@v-cyu @v-kmc 

[MaxZ1]

Hey Guys,

I'm expierencing the same issue in my company. If anyone know how to solve this, could you please please share it with us. Thanks very much in advance!

[3CloudThomas]

I do not know the answer to that. Did someone at your company make this change? Or is it a thrid party source to your report?

[3CloudThomas]

AtScale is a tthrid-party tools that replaces SSAS and can convert a model to AtScale. Someone had to intentially do this at the source. You need to find or contact the person\group who made the change

[Dzunic]

I am facing the same issue. Microsoft is working on that.

[gayatrisr]

Is there a way to change it back to SSAS? I dont think anyone will be admitting this mistake. 

[LucieP]

Hi!

I am experiencing the same kind of issue in my organization and we can't track back where the change has been made.

How did you solve this?

[gayatrisr]

I had to rebuild the reports as they were critical. There wasn't any other solution available.