Forum Discussion
Pipeline Copy Activity unable to copy delta table to local SQL server
Hi TWorku,
Thank you for the clarification that makes complete sense, and your approach is valid.
What you are seeing aligns with current Fabric behaviour: when copying directly from a Lakehouse, DATE columns can be exposed as high-precision DateTime metadata at runtime, which causes SQL Server conversion failures. By merging the data into a Warehouse first, the schema is normalized to strict relational types, which is why the subsequent copy to local SQL Server runs successfully and within an expected time frame.
Given your requirement to keep source data types unchanged, this Warehouse-based pattern is a solid and supported design choice. While it does introduce an additional object to manage, it avoids the staging performance penalty and provides predictable copy behaviour. Until the Lakehouse Copy metadata handling is improved, this is one of the most reliable solutions for production workloads.Hope that clarifies. Let us know if you have any doubts regarding this. We will be happy to help.
Thank you for using the Microsoft Fabric Community Forum.
Good morning v-kpoloju-msft
Thanks for your reply. Our implemented flow is: merge data into a warehouse via a stored procedure, then copy it to the local SQL server. The copy step averages 3 minutes. We are committed to not changing source data types. Yes, this means an extra table and activity to manage, but it's the most suitable solution we have.
Community SupportHi TWorku,
Thank you for the clarification that makes complete sense, and your approach is valid.
What you are seeing aligns with current Fabric behaviour: when copying directly from a Lakehouse, DATE columns can be exposed as high-precision DateTime metadata at runtime, which causes SQL Server conversion failures. By merging the data into a Warehouse first, the schema is normalized to strict relational types, which is why the subsequent copy to local SQL Server runs successfully and within an expected time frame.
Given your requirement to keep source data types unchanged, this Warehouse-based pattern is a solid and supported design choice. While it does introduce an additional object to manage, it avoids the staging performance penalty and provides predictable copy behaviour. Until the Lakehouse Copy metadata handling is improved, this is one of the most reliable solutions for production workloads.
Hope that clarifies. Let us know if you have any doubts regarding this. We will be happy to help.
Thank you for using the Microsoft Fabric Community Forum.
- v-kpoloju-msft
Hi TWorku,
Just checking in to see if the issue has been resolved on your end. If the earlier suggestions helped, that’s great to hear! And if you’re still facing challenges, feel free to share more details happy to assist further.Thank you.
- v-kpoloju-msft
Hi TWorku,
Just wanted to follow up. If the shared guidance worked for you, that’s wonderful hopefully it also helps others looking for similar answers. If there’s anything else you'd like to explore or clarify, don’t hesitate to reach out.Thank you.