How to restore / migrate / copy the stored procedures and view across / to another workspaces?

[mikeburek]

I want to copy the stored procedures from a Fabric SQL database in one workspace to another workspace.

The only options I see are:

* Move to another folder within the same workspace

* Restore the full database with code and data to a new name within the same workspace

I know how to copy data.

[mikeburek · Accepted solution]

There is no solution to do this within Fabric at this time.

There are workarounds with external tools, and some of those methods are the same as a plain SQL Server database.

The reply from deborshi_nag is the closest to how to do it in a Fabric method.

[KevinChant]

Hi, I thought I better add to this thread as some details are missing. If you want to do it manually you can use Visual Studio locally to connect to the database and extract the stored procedures manually. To do this with Visual Studio Code you mill need to install the MSSQL extension.

If you want to automate this either initialize the folder the local database is stored in as a Git repository is in and synchronize it, or configure the workspace it is in with Git integration. From there you can either create a dacpac to deploy all at once or use another mechanism to deploy the .sql files individually.

I hope this helps.

[Murtaza_Ghafoor]

Unfortunately, there is no copy or restore option available in fabric, currently
1-views
2-SP
3-Functions
are tightly bound to workspace level.

The best approch is to Script Object in Git + Redeploy ti another workspace is best option at the moment, thanks

 

[deborshi_nag]

Hello @mikeburek 

SQL stored procedures can be version-controlled in GitHub and deployed across different databases, but there are a few considerations:

How It Works

1. Store Procedures as Scripts

   • You export the stored procedure definitions as .sql files (e.g., CreateProcedure.sql).
   • These files can be committed to a GitHub repository like any other code.

2. Version Control Benefits

   • GitHub tracks changes, enabling collaboration, rollback, and auditing.
   • You can use branches for development, testing, and production environments.

3. Moving Between Databases

   • To deploy to another database, you run the .sql scripts against the target database using tools like:
     • SQL Server Management Studio (SSMS) or Azure Data Studio
     • Command-line tools (sqlcmd)
     • CI/CD pipelines (e.g., Azure DevOps, GitHub Actions) for automated deployment.

4. Best Practices

   • Parameterise database names or use environment-specific configuration files.
   • Include DROP/CREATE or ALTER statements in scripts for idempotency.

Hope this helps - please appreciate by leaving a Kudos or accepting as a Solution! 

[v-sshirivolu]

Hi @mikeburek ,
SqlPackage is a command-line utility (CLI) you can use with SQL databases in Microsoft Fabric to support database portability and deployment tasks. It lets you extract database definitions (schema), views, stored procedures, functions, and more into a .dacpac file, publish those definitions to an existing or new database, and import/export database copies using files such as .bacpac. This makes it easier to manage, migrate, and deploy changes to your Fabric SQL database . You can install and run SqlPackage on Windows, macOS, or Linux using the .NET SDK tool.

For further steps on how to use SqlPackage, Please refer:
SqlPackage for SQL database - Microsoft Fabric | Microsoft Learn

[v-sshirivolu]

Hi @mikeburek ,

I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.

[v-sshirivolu]

HI @mikeburek ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. 

[tayloramy]

Hi @mikeburek, 

I don't believe there is any direct way to copy DDL from one SQL database to another. What I would recommend is you script out the procedures, and then re-create them in the new SQL database.