Error when trying to edit a Semantic Model in a Warehouse

[ToddChitt]

I have a Warehouse and Semantic Model. I am trying to do some basic stuff that was fairly ubiqutious in Power BI Desktop, like set the Display folder property, or set the Summarize By property of a numeric field. But the funny thing is: the error mentions a table name that is NOT the table that contains the field I am trying to edit. The error mentions my dimDate table, which was recently dropped, recreated and re-populated with additional columns (because you can't do ALTER TABLE ADD <column> in Fabric Data Waterhouses), and my Power BI model (connected via Direct Lake) only shows the OLD version of dimDate without the extra columns. 

It's like something is stuck and that there are TWO tables named dimDate that is causing conflicts. I did a DROP TABLE dbo.dimDate, and the Warehouse Semantic model picked up that fact immediately. But my Power BI file does not, even after a refresh. What's more, I create a new Power BI file and connect it via Direct Lake to the Warehouse and it sees the old dimDate table (that is no longer there).

How do I get my Power BI Direct Lake model to recognize the Semantic Model in its entirety, with nothing extra?

Oh, and even after deleting dimDate, I still cannot assign a Display Folder to a column. 

IMHO, Fabric is NOT ready for prime-time 😞

[v-cboorla-msft]

Hi @ToddChitt 

Thanks for using Microsoft Fabric Community.

Apologize for the inconvenience that you are facing.

There might be a chance of an intermittent issue when creating/removing relationships via the model view.

Could you please try again by recreate the connection between Power BI and your Warehouse.

If the issue still persists, please do let us know. Glad to help.

I hope this information helps.

Thanks.

[ToddChitt]

Seems I forgot about editing the Default Semantic Model to include the new dimDate table. So the Power BI Direct Lake connection was simply going off of the most recent schema it had of the Semantic Model, which included an old dimDate table with only one column (but had been deleted). I see this as a bug: If I delete a table out of my Warehouse that is part of the Default Semantic Model, consumers of that model don't seem to know about it's deletion and A) will show it in the Power BI Model View, and B) Power BI will constantly crash when trying to open a PBIX file that is connected via Direct Lake to that model.

[ToddChitt]

Moving on, I noticed that my Power BI model has only 3,859 rows in dimDate table (I tried to populate it from 1/1/2020 through 12/31/2030, but it ended at 7/25/2030) and this was what Power BI showed. After this, I did finish populating it to the full 4,018 rows, but Power BI still shows 3,859, even after refresh. 

At one point, I was looking at three different versions of this table:

* SSMS had all rows, and all columns populated

* Fabric Warehouse shows all rows, but only the first column populated 

* Power BI had a subset of rows. 

I click the refresh button on the Warehouse and nothing changes.

I REMOVE the table from the Default Model then re-add it and now Power BI and SSMS line up, but the Warehouse Data View is still showing NULL for most columns:

I say this again: Fabric is NOT ready for Prime Time!

[v-cboorla-msft]

Hi @ToddChitt 

Apologies for the issue you have been facing and delay in the response from my end.

It's difficult to tell what could be the reason for this performance. 

Please reach out to our support team so they can do a thorough investigation on why this is happening. Our support engineers would definitely understand the root cause and properly address it.

Please go ahead and raise a support ticket to reach our support team:

https://support.fabric.microsoft.com/support

After creating a Support ticket please provide the ticket number as it would help us to track for more information.

Thank you.

[v-cboorla-msft]

Hi @ToddChitt 

Did you got a chance to raise a support ticket with our team through? If you did, please let me know the ticket number as it would help us to track for more information.

Thanks.