Forum Discussion
Semantic Model: Error on refresh and not gracefully
Setup
We use dbt to run SQL transformation files that load data into a fabric data warehouse.
We use fabric pipelines to call dbt to run those scripts and when they finish it triggers the semantic model refresh.
Error
The semantic model error says an object doesn't exist when it tries to refresh. It's not consistent what table it doesn't think isn't there. It seems like after dbt loads all of the data (it takes about 4 mins for this step), Fabric semantic models don't always know the tables exist.
Troubleshooting
-This happens maybe once a day. Sometimes less sometimes much more. It's very random.
-When it happens I've gone to the Fabric Data Warehouse through the fabric UI and the table that the semantic model thinks doesn't exist is definetly there. I can even query it and create a report using it.
-Sometimes I just manually refresh the semantic model and it works.
-Sometimes manual refreshes don't work. If that's the case I rerun that table script in dbt and that always fixes it.
Issue
The reason this is a problem is that fabric onelake semantic models don't error gracefully. If it thinks an object doesn't exist, the entire semantic model doesn't work. Power BI reports show an error "fetching data". This is frustrating and significant for our executive team reports since it was promised that Fabric is "magical" 😄
Possible Solutions
Because of the randomness, we have implemented my absolutely least favorite solution and just hardcoded in some wait times. It appears that fabric just needs some time to realise tables exist. This has helped some, but sometimes it needs more time we guess?
Is there a way to force fabric to refresh the table schema before refreshing a semantic model? Maybe that could help.
Request to Microsoft/Fabric
If a OneLake semantic model refresh fails, don't make the data corrupt...If this error didn't break every report the semantic model uses, we wouldn't care about one error a day.
Update on this. We have implemented a solution that is working for anyone else struggling with this.
With the help of some very talented engineers, we impletmented a custom dbt materialization method that no longer drops and creates tables on refresh. Ever since that change, we haven't had any errors with the semantic model refresh.
This adds to the suspision that fabric has some bugs with how it handles the parque file relationships.
I'll mark this as the solution. Happy coding everyone.
11 Replies
Update on this. We have implemented a solution that is working for anyone else struggling with this.
With the help of some very talented engineers, we impletmented a custom dbt materialization method that no longer drops and creates tables on refresh. Ever since that change, we haven't had any errors with the semantic model refresh.
This adds to the suspision that fabric has some bugs with how it handles the parque file relationships.
I'll mark this as the solution. Happy coding everyone.
If this helps, here is a list of the times this error has happened since 7/18. As you can see...it's very random and always the same error. The semantic model thinks some object doesn't exist.
Hi NoDice ,
Thanks for reaching out to the Microsoft fabric community forum.
Once try the below workarounds:- Implement retry logic with backoff instead of fixed delays.
- Test with a custom semantic model for more refresh control.
- Optionally, disable auto-refresh and trigger manually via pipeline.
If I misunderstand your needs or you still have problems on it, please feel free to let us know.  
Best Regards,
Community Support Team
This seems to be an underlying issue of how Direct Lake mode works specifically when referencing a Warehouse. When a table is dropped and recreated, the semantic model occassionally appears to lose the reference for the current Parquet file, which then makes the model inaccessible.
The only way I have found to remedy this is to:
- Drop the table that is creating the error.- Recreate the table.
- Update the model via the edit tables button in the Edit Semantic Model UI.
This is a long-standing bug that pops up with Direct Lake models that reference a warehouse. It seems that Microsoft internally can either not reproduce the bug, or does not have the will to resolve it. It is also frustrating that there appears to be no way to programmatically call the process equivalent to using the Edit Tables menu in the UI.
