Forum Discussion
Delta shallow clone not visible via SQL endpoint
Context
In fabric lakehouse there are two entry points 1. spark cluster 2. SQL endpoint and lakehouse provides delta shallow clone feature.
Problem
When i create a shallow clone and then i switch to sql endpoint mode and wait for few minutes and then refresh the tab then this error comes for that shallow clone table,
DeltaTableUserException: Absolute file path is not supported
In Lakehouse Explorer shallow clone table is visible and also queryable, issue seems only with SQL endpoint and SQL endpoint can query other tables too, so it's not corrupted.
Based on your observations this appears to be a SQL analytics endpoint limitation or metadata synchronization issue related to Delta shallow clones, rather than corruption of the cloned table itself.
The key indicators are:
- The shallow clone is visible in Lakehouse Explorer.
- The table can be queried successfully through Spark.
- Other tables remain queryable through the SQL analytics endpoint.
- The failure occurs only for the shallow-cloned table and returns:
DeltaTableUserException: Absolute file path is not supported
A Delta SHALLOW CLONE creates a new Delta table that references the source table's existing data files rather than copying them. Since Spark can read the clone successfully, the Delta table metadata itself appears valid.
The issue is likely occurring when the SQL analytics endpoint attempts to discover or synchronize metadata for the cloned table. The error message suggests that the endpoint is encountering file path references that it cannot resolve or process correctly.
To further validate this, you can try the following:
-
- Verify that the cloned table exists under the Lakehouse Tables area and is not being treated as an external table.
- Allow additional time for SQL endpoint metadata synchronization and refresh the endpoint.
- Create a shallow clone of a small test table and check whether it can be queried through the SQL endpoint.
- Create a copy using CTAS and compare the behavior:
CREATE TABLE test_copy
AS
SELECT *
FROM source_table;
If the copied table works through the SQL analytics endpoint while the shallow clone fails, it would strongly indicate an issue specific to SQL endpoint handling of shallow-clone metadata.
Based on the information provided I would focus the investigation on SQL analytics endpoint support for shallowcloned Delta tables rather than on repairing or rebuilding the Delta table itself.
HTH!
Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.
4 Replies
- Vinodh247
Super User
Based on your observations this appears to be a SQL analytics endpoint limitation or metadata synchronization issue related to Delta shallow clones, rather than corruption of the cloned table itself.
The key indicators are:
- The shallow clone is visible in Lakehouse Explorer.
- The table can be queried successfully through Spark.
- Other tables remain queryable through the SQL analytics endpoint.
- The failure occurs only for the shallow-cloned table and returns:
DeltaTableUserException: Absolute file path is not supported
A Delta SHALLOW CLONE creates a new Delta table that references the source table's existing data files rather than copying them. Since Spark can read the clone successfully, the Delta table metadata itself appears valid.
The issue is likely occurring when the SQL analytics endpoint attempts to discover or synchronize metadata for the cloned table. The error message suggests that the endpoint is encountering file path references that it cannot resolve or process correctly.
To further validate this, you can try the following:
-
- Verify that the cloned table exists under the Lakehouse Tables area and is not being treated as an external table.
- Allow additional time for SQL endpoint metadata synchronization and refresh the endpoint.
- Create a shallow clone of a small test table and check whether it can be queried through the SQL endpoint.
- Create a copy using CTAS and compare the behavior:
CREATE TABLE test_copy
AS
SELECT *
FROM source_table;
If the copied table works through the SQL analytics endpoint while the shallow clone fails, it would strongly indicate an issue specific to SQL endpoint handling of shallow-clone metadata.
Based on the information provided I would focus the investigation on SQL analytics endpoint support for shallowcloned Delta tables rather than on repairing or rebuilding the Delta table itself.
HTH!
Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.
- ShivekMaharaj
Solution Sage
Hi pradipsodha,
Vinodh247's diagnosis looks consistent with what you are seeing. One nuance is that I don't think Microsoft currently documents this specifically as a supported/unsupported shallow-clone scenario for the SQL analytics endpoint.
The Delta shallow clone documentation explains that a shallow clone copies the Delta metadata but references the source table's existing OneLake data files rather than copying them.
That makes the error you are getting particularly interesting:
DeltaTableUserException: Absolute file path is not supportedSince the clone remains queryable through Spark but fails during SQL endpoint table synchronization, this looks more like a current cross-engine interoperability gap around the clone's file references than corruption of the Delta table itself.
I also would not expect additional waiting to help much here. Your screenshot shows Table sync status = Failure, so the endpoint has already attempted to process the table rather than simply waiting for normal SQL analytics endpoint metadata synchronization.
If SQL endpoint access is required, I would test materializing the clone/source into an independent Delta table, for example with a full CREATE TABLE ... AS SELECT. That writes new data files instead of retaining the shallow references and should also give you a useful A/B test.
If the materialized table synchronizes while the shallow clone consistently returns the absolute-path error, I would raise that reproduction with Microsoft because I couldn't find an official SQL analytics endpoint limitation that explicitly calls out Delta shallow clones.
For zero-copy access without point-in-time clone semantics, a OneLake shortcut is another option because shortcut Delta tables are supported by the SQL analytics endpoint, but that would continue referencing the live source rather than giving you a shallow-clone snapshot.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
v-aatheequeCommunity Support
Hi pradipsodha
Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.
- v-aatheeque
Hi pradipsodha
We wanted to follow up to check if you’ve had an opportunity to review the previous responses. If you require further assistance, please don’t hesitate to let us know.
