Forum Discussion
Copy Activity creates incorrect Lakehouse schema (schema name replaced by table name)
Hi seba_garces_crz ,
Thank you for providing the screenshots and additional information. From what I can see, the Copy Activity is configured with distinct values for the Lakehouse schema and table name and there are no apparent setup issues that would explain the behavior you're experiencing.
Given that the pipeline functioned correctly until late May and is now creating objects under an unexpected schema, this does not seem to be a typical configuration problem. Your tests with alternative schema naming also led to the same outcome indicating the issue may not stem from the activity's defined values.
Could you review the Input and Output details from a recent pipeline run to verify whether the schema and table values are being passed accurately at execution time If these values are correct in the run details but the Lakehouse still creates objects under the wrong schema, it may indicate a service-side issue rather than a configuration error.
If the execution payload confirms the expected schema and table names, I suggest opening a Microsoft Fabric support ticket and including the pipeline run ID workspace details, and your screenshots. The observed behavior in the Lakehouse structure does not align with the sink configuration, and the Fabric engineering team may need to determine if a recent platform update is affecting Copy Activity writes to schema enabled Lakehouses.
Thank you.
6 Replies
Hi seba_garces_crz ,
That's quite strange. Based on what you're describing, it should work correctly.
Could you share a screenshot of how the Copy Data activity is configured? That would help us review the setup and see if there's anything we're missing.
It could also be that the schema variables are not being resolved correctly. Have you checked the execution input/output? That should show whether the schema value is being passed as expected or if it's coming through empty, incorrectly formatted, or with a different value than intended.
As a quick test, I would also try hardcoding the schema temporarily to see if the behavior remains the same.
If this response has been helpful, please don't forget to give it a Like and mark it as a Solution so other community members can find it easily.
Thank you!
This is a Copy Data configured screenshots.
Source:
Destination:
This configuration was working correctly until May 26, but for some reason the data is now being stored in the following structure (see next image).I have tried some workarounds, such as inserting a new table using lowercase letters for the schema name (as suggested in this post), but without success.Hi seba_garces_crz ,
Thank you for providing the screenshots and additional information. From what I can see, the Copy Activity is configured with distinct values for the Lakehouse schema and table name and there are no apparent setup issues that would explain the behavior you're experiencing.
Given that the pipeline functioned correctly until late May and is now creating objects under an unexpected schema, this does not seem to be a typical configuration problem. Your tests with alternative schema naming also led to the same outcome indicating the issue may not stem from the activity's defined values.
Could you review the Input and Output details from a recent pipeline run to verify whether the schema and table values are being passed accurately at execution time If these values are correct in the run details but the Lakehouse still creates objects under the wrong schema, it may indicate a service-side issue rather than a configuration error.
If the execution payload confirms the expected schema and table names, I suggest opening a Microsoft Fabric support ticket and including the pipeline run ID workspace details, and your screenshots. The observed behavior in the Lakehouse structure does not align with the sink configuration, and the Fabric engineering team may need to determine if a recent platform update is affecting Copy Activity writes to schema enabled Lakehouses.
Thank you.
Please share a screenshot of the Copy Data activity configuration. Also, check the activity input/output to confirm the schema variable is resolving correctly. As a quick test, try hardcoding the schema name to see if the issue persists.
