Quick answer: If a managed Fabric Lakehouse table is dropped and its location still causes DELTA_CREATE_TABLE_WITH_NON_EMPTY_LOCATION, first determine whether the table is managed or external and inspect the remaining location. For managed Delta tables, Microsoft documents that dropping the table removes its metadata and underlying data files. If files remain because of a failed operation or because you are working with an external location, inspect and clean the location carefully rather than treating manual deletion as the normal managed-table workflow.
In the example below, we want to drop and recreate a table lh_gold.t_fact_day_sales in a Fabric Lakehouse.
Error message
The error reported in the original scenario is:
AnalysisException: [DELTA_CREATE_TABLE_WITH_NON_EMPTY_LOCATION] Cannot create table (‘lh_gold.t_fact_day_sales’). The associated location is not empty and also not a Delta table.
Why a Fabric Lakehouse location can still contain files
Microsoft Fabric uses OneLake as its unified storage layer. The cleanup behavior depends on how the table and its location are managed. A managed table is owned by the Lakehouse and has its storage managed by Fabric. An external table points to a location specified by the user, so dropping the table does not mean that the external data location should automatically be treated as disposable.
For a managed Delta table, Microsoft documents that DROP TABLE removes the table metadata and the underlying data files. Therefore, manually deleting a managed table folder should not be the first-line solution. If the location is still non-empty after an unsuccessful operation, inspect the location and determine what remains before removing anything.
Troubleshoot a non-empty Lakehouse table location
1. Confirm the table and location. Check whether the table is managed or external and verify the location shown in the error. Do not assume that every path under Tables/ can be safely deleted.
2. Inspect the remaining files. Fabric notebooks can use notebookutils.fs for file-system operations. The following example lists the contents of a OneLake path. Replace the path with your own Lakehouse location.
path = "abfss://<workspace-id>@onelake.dfs.fabric.microsoft.com/<item-id>/Tables/t_fact_day_sales"
files = notebookutils.fs.ls(path)
display(files)
3. Do not recursively delete a managed table location just to make CREATE TABLE succeed. If the table is managed, use the Lakehouse table operation and investigate why the location remains. If the location belongs to an external table or another workload, verify ownership and retention requirements before deleting files.
4. Drop the table when appropriate.
DROP TABLE IF EXISTS lh_gold.t_fact_day_sales;
5. Recreate the managed Lakehouse table. For a managed Lakehouse table, create the table through the supported Lakehouse experience or SQL interface rather than manually pointing a managed table at an arbitrary OneLake folder. If you intentionally use an external location, follow the supported external-table pattern for that workload and retain ownership of the external data.
When manual file deletion is appropriate
Manual deletion should be treated as a controlled cleanup operation, not as the standard way to remove files belonging to a managed Lakehouse table. For an external location, or for files that you have confirmed are orphaned and safe to remove, use the appropriate OneLake file-management tool or API and verify the path before deletion.
Common causes to check
- Managed vs. external table: confirm which table type you are using before deleting anything.
- Failed or interrupted operation: inspect the location when the table operation did not complete normally.
- Incorrect location: verify the path in the error instead of deleting an entire Lakehouse folder.
- Non-Delta content: the error specifically indicates that the target location is non-empty and is not recognized as the expected Delta table location.
Related storage guidance: For Azure Blob Storage lifecycle-based cleanup, see Automatically Delete Old Files from Azure Storage with Lifecycle Management.
Pro tips:
1. Treat managed Lakehouse table storage as Fabric-managed data; don’t recursively delete its folder as a routine fix.
2. For file-system operations in Fabric notebooks, prefer the current notebookutils.fs API rather than older notebookutils examples.
3. Before deleting an external or orphaned location, confirm its ownership and that no table, shortcut, pipeline, or other workload depends on it.
See more
Visual Studio Marketplace
SSIS Catalog Migration Wizard
Extend Visual Studio with an easy way to migrate SSIS Catalog projects.
Jagdish Wagh
Jagdish is a seasoned Solution and Cloud Architect with over a decade of experience in data engineering, BI, and analytics. He is specialised in Microsoft cloud and Databricks solutions.
