Forum Discussion
Copy Job item appears to hardcode database name resulting in issues after CI/CD deployment
We have a Copy Job item that uses an on-prem SQL Server as its source. The connection has been parameterized. When deployed to the prod workspace, the source activity is expecting the same database n...
You're running into a current limitation of Fabric Copy Job: while you can bind the connection object to a Variable Library (and thus change servers/credentials across environments), the database name in the Copy Job’s SQL source is not parameterizable—it remains a hard‑coded string in the job definition. That’s why, when you deploy to Prod, the source still points to the Dev database name. This behavior has been reported by others and documented with JSON snippets showing the connection variable is respected but the
database property stays literal.One workaround is:
Use a Pipeline → Copy activity instead of Copy Job, and parameterize inside the activity
Pipelines give you more knobs than Copy Jobs. For SQL sources in a Copy activity, you can:
- Switch to Query or Stored procedure mode and parametrize inputs (e.g., pass a database‑specific schema or table list, or drive routing with parameters) rather than relying on the “Table” picker that bakes in a DB name.
- Combine with Variable Libraries for connection selection at runtime (servers/credentials), which are supported for pipelines.
- Configure SQL database in a copy activity (Preview) - Microsoft Fabric | Microsoft Learn
- SQL database connector overview (Preview) - Microsoft Fabric | Microsoft Learn
- Parameterize Connections in Microsoft Fabric Data Factory using Variable Libraries – SQLServerCentral