Forum Discussion
Fabric Default Schema Lakehouse
So for a Notebook i use this to define the defaultLakehouse:
%%configure -f
{
"defaultLakehouse": {
"name": "test"
}
}Here "test" is a Lakehouse without activating Lakehouse-Schemas. If i run this
spark.sql("DESCRIBE TABLE publicholidays").show()It works without any issues, it takes the "test" Lakehouse from the current Workspace and shows me the result.
But now if "test" is a Lakehouse with activating Lakehouse-Schemas, when running the spark.sql i run into this error even tho i specify the schema like DESCRIBE TABLE dbo.publicholidays:
An error occurred while calling o348.sql. : com.microsoft.fabric.spark.catalog.metadata.DoesNotExistException: Artifact not found: `<no-lakehouse-workspace-specified>`.`test`
Why does this happen and is there any fix?
Hi danitskofabric,
Currently %%configure with only the lakehouse name works only when schemas are disabled.
When schemas are enabled, fabric requires both the lakehouse Id and workspaceId for binding, so fully portable notebooks need to fetch these Id’s dynamically at runtime. As of now there is no way to avoid Id’s completely, it is a current limitation of schema enabled lakehouses.I recommend submitting your detailed feedback and ideas through Microsoft's official feedback channels. Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements.
Fabric Ideas - Microsoft Fabric Community
Thanks and regards,
Anjan Kumar Chippa
8 Replies
Hi danitskofabric ,
I performed two tests.
First, I created a table and then executed the scripts.
Both worked with a schema-enabled lakehouse.Did you do the same thing?
See the Screenshots:
Best regards
Hi spaceman127,
Thank You for your reply.
If I manually add the lakehouse it works without any problems, but im trying to bind it via %%configure.
When Lakehouse-Schemas are off, %%configure defaultLakehouse auto-binds tables.
When on, Fabric needs the full 3-part name → lakehouse.schema.table.✅ Fix:
Use DESCRIBE TABLE test.dbo.publicholidays (not just dbo.publicholidays), or
Run spark.sql("USE test.dbo") before queries.
defaultLakehouse doesn’t handle schemas automatically.
Hi Shahid12523,
Thank You for your reply.
Unfortunately that makes me run into the same issue.
spark.sql("DESCRIBE TABLE test.dbo.publicholidays").show()Still getting the same error message.
Hi danitskofabric,
Thank you for reaching out to Microsoft Fabric Community.
Thank you spaceman127 and Shahid12523 for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa
Hi danitskofabric,
When lakehouse schemas is enabled, %%configure with only name: test does not create the internal binding the spark session needs. We need to include the lakehouse id and workspace id in the default lakehouse block and run that %%configure as the very first cell. Please follow below steps:
- Get the lakehouse id and workspace id
- Make sure the first cell of the notebook is the configure cell. If you already executed other spark work, restart the session and make the following the first cell. %%configure must run before spark is initialized.
- Put this as the very first cell and paste the lakehouse-Id and Workspace-Id you got:
%%configure -f
{
"defaultLakehouse": {
"name": "test",
"id": "lakehouse-Id",
"workspaceId": "Workspace-Id"
}
} - And then run this, it will work
spark.sql("DESCRIBE TABLE test.dbo.publicholidays").show()
Thanks and regards,
Anjan Kumar Chippa
Hi v-achippa,
Thank you for your reply. Yes, I figured that out, but what I’m trying to achieve is that I don’t have to specify any IDs, so the same code works in different workspaces and automatically uses the lakehouse from the current workspace. Unfortunately, this seems only to work for lakehouses without schema enabled.
Hi danitskofabric,
Currently %%configure with only the lakehouse name works only when schemas are disabled.
When schemas are enabled, fabric requires both the lakehouse Id and workspaceId for binding, so fully portable notebooks need to fetch these Id’s dynamically at runtime. As of now there is no way to avoid Id’s completely, it is a current limitation of schema enabled lakehouses.I recommend submitting your detailed feedback and ideas through Microsoft's official feedback channels. Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements.
Fabric Ideas - Microsoft Fabric Community
Thanks and regards,
Anjan Kumar Chippa
