I am planning to move a SQL Server database (with procedure calls and 200+ tables) to version control (github) and deploy using DACPAC. I imported my database into Visual Studio 2017, but I don't have any idea how I will maintain database version and deploy change set
After you imported into VS 2017, you should see the SQL project with all your database objects including tables, stored procedures, functions, views, etc in the folder where you saved in Visual Studio. You can check-in this SQL Project folder with all its contents into GitHub. Use a suitable gitignore file like this https://github.com/gertd/sqlproj/blob/master/.gitignore to avoid cluttering GitHub with non-code files.
You need to make changes in the Visual Studio for any change in database objects and commit/push to GitHub. If you prefer you can make change in SQL Server directly and then update your Visual Studio project using the schema compare feature, before you push to GitHub.
To deploy, you can build the SqlProject from Visual Studio which will create/update a dacpac.
Related
I need to automate SQL Server DB deployment using Azure DevOps. I don't want to give any alter statement. I will have a folder structure with tables, stored procedures, views & functions in repository. Every folder will contain only create scripts. Is there anyway to create DacPac file with that folder structure or any other way, other than DacPac deployment using that folder structure?
Note: I don't want to create DB project using Visual Studio. And I don't want to create a DacPac file directly from SQL Server Management Studio and checkin the same to source control. And I am not in a situation to pay for license.
You can try to use SQL Database Projects extension in Azure Data Sudio. It supports VS SQL Database Project and it supports builds from the command line: Build a database project from command line
What you describe is the database project. A dacpac is the build output of a Database project. There are no licenses involved. All the tools that produce dacpac files are free:
Both SQL Server Data Tools (SSDT) and SQL Server Management Studio (SSMS) are free, standalone downloads.
You can install SSDT on top of Visual Studio Community which is also free.
Azure Data Studio supports database projects. Also free, open source and works on Mac and Linux. I'm using it on Mac to edit database projects, using a SQL Server Developer Edition in a Docker container.
The sqlpackage command-line tool can extract a dacpac from an existing database, publish it or generate a migration script. Also free and a standalone download
I am working on SQL Database Project in the Visual Studio 2017. Purpose is to push only the Stored Procedure Changes to VSTS Git.
Instead of connecting to the Database from the Project Solution, I am using Import SQL Scripts.
In this approach, any changes in the stored procedure has to be copied and pasted on the stored procedure in the Project Solution.
How to set the SQL Database Project in the Visual Studio 2017 connected to the Database? And Connecting to the Database should not allow Import option to extract the all other database objects such as Table, View from SQL to Visual Studio. We do not want all other scripts. We just need only those Stored Procedures to be sync with database environment.
At present, we are making the changes to the Stored Procedures in the SQL Management Studio. Further then, we manually copy the SQL Script from SQL Management Studio to Visual Studio Environment.
Whether, will it be possible for us to have the changes auto-sync between SQL Management Studio to Visual Studio (or) by refreshing the Visual Studio Project.
In Visual Studio, go to Tools -> SQL Server -> Schema Compare. At the top of the new window, access the dropdown, and put your local DB connection (where you've added the stored procedure) on the left, and your DB project on the right. Hit Compare, and then Update. This should update the dbo directory in your Database project to match the local db schema, whether you're adding 1 proc or 100.
At this point, you'll also need to add a reference to the stored procedure to your database project in VS. Put the .sqlproj into a text editor, add the reference (there will be lots of examples to copy; it should be easy), save, and build the project to make sure you got it right. git add, commit, and push!
This only works if the schema of your local DB matches what is in the VS project. If you want to copy something from a database with a different schema, I think you're stuck copy-pasting.
AFAIK, there is no way to automate this, but I would love to be corrected about that. It would save me so much time at work. :)
I am having a hard time figuring how to actually create or even open a DAC application with Visual Studio 2012. I am using SQL Server 2012. I have SSDT installed.
Creating from Visual Studio:
According to online documentation I should be able to see a project template with the name "Data Tier Application" but all I see is SQL Server Database Project. Are they the same?
Creating from SSMS:
In an online video the presenter is using SSMS -> Database -> Right Click -> Create Project menu item, and after the wizard a VS project is popped open. I do not have this menu item, what I have is Tasks -> Export as Data Tier Application. This creates the DACPAC file but not the VS project, and I could not figure out how to open a dacpac from VS.
The purpose of a DACPAC is to provide a portable representation of a database schema, that can be used to deploy that schema to a database, import it into a database project in Visual Studio, and be used in functions like Schema Compare to examine differences between different sources. Whenever you build a database project in Visual Studio a .dacpac file will be generated, and this can then be used to deploy the schema defined in that project to a database.
The best place for full information is the SSDT help, but I'll give you a quick summary.
If you already have a DACPAC, you can use it in VS in the following ways:
Import the schema into a project by right-clicking on the project in Solution Explorer and choosing "Import -> Data-tier Application (*.dacpac)". Then choose your dacpac, and the contents will be converted into SQL Scripts and added to the project
Publish the dacpac to a database by opening SQL Server Object Explorer, navigating to a server, right-clicking on Databases and choosing "Publish Data-tier Application..." This will publish the contents of a DACPAC up to a database on that server. You could update a database by right-clicking on a database in the Databases list. Note that if the SQL Server Object Explorer view isn't open, you can select "View -> SQL Server Object Explorer" to ensure it appears.
To create a DACPAC in Visual Studio, you can
Build a project. This creates a dacpac in the bin\Debug directory (assuming you build in Debug mode).
Snapshot a project. This creates a dacpac and saves it in the project. It's very useful to track point in time versions of your database schema and compare previous versions of the database to the latest definitions.
Right-click on a database in SQL Server Object Explorer and choose "Extract Data-tier Application..." This will create a dacpac that represents the database contents.
Finally I'm not sure what video you viewed, but it's possible they showed right-clicking on a DB in SQL Server Object Explorer and creating a project from there. That's a very common way to start development using a database project, since often you'll already have a database containing your schema. Generally the best practices would be to develop using a project, and use dacpacs (and possibly command line deployment tools like SqlPackage.exe) when deploying out to different environments such as your production servers (again dacpacs are great for transporting schema definitions and deploying them to different environments). Hope this helps answer your question!
Fairly long title, but hopefully self-explanatory!
I'm starting a new project in Visual Studio 2013 using Entity Framework 5.0 with code first migrations.
I've connected my project to TFS Online using git - I'm interested in trying TFS Online as it offers source control management for 5 free projects (similar to BitBucket) but with strong Visual Studio integration.
I've not used Database projects in Visual Studio 2013 and I've found little information for how this all fits together.
What I'm trying to acheive is to create a simple Visual Studio solution with 2 projects - one an MVC .NET project and the other a database project. My goal is that code first migrations will make the neccessary changes to the sql scripts in the database project (which are managed under git source control). My web.config points to a local .mdb file as my database which is what is updated when I run update-database in EF which is what I feel is the problem.
How can I point EF to use my database project for code migration, and subsequently how can I automatically build my development database into a local .mdb file when debugging my solution?
Entity Framework Code First is a way to manage your SQL Schema. The single source of the truth lives in your code base. Migrations adds a way to move from one version of the schema to another. The SQL schema is a by-product of the build process.
SQL Server Database projects are also a way to manage your SQL Schema. The single source of the truth lives in your SQL Server Database project. You can use schema compare to generate scripts that move from one version to another.
Given that these technologies overlap in their intent and functionality, it doesn't really make sense to use them together. When you're using entity Framework Code First, leverage Migrations when you can (and when the features are sufficient for your situation).
When you're unable to use Migrations, you could use SQL Server Database projects to manage the schema and keep them in source control.
Note:
You should consider installing the SQL Server Data Tools as a replacement for the SQL Server Database projects should you want to use these. The data tools are a more advanced version of these projects, even if they might require Visual Studio 2012 to run for now. I suspect a version for Visual Studio 2013 will be available when Visual Studio 2013 hits RTM
I am running SQL Server 2012 and VS 2010 with SSDT (SQL Server Data Tools) installed. My dev DB uses stored procs, functions, CLR objects, etc. It has a snapshot of prod data of about 500GB.
I created SQL Server Database Project and then imported the database. This created all tables, views, procs and functions files under schema names. Great stuff -- now I can do a version control just like in other VS projects, create deployments, etc. So far, so good.
But, I am confused as to what my development process should be for changing/adding procs/tables under SQL Server Database Project. It appears that any changes I make are applied to some LocalDb/Projects database and NOT to my dev database.
Am I suppose to author all my objects in that LocalDb, then Build and deploy to my dev database via Publish? I am worried about my existing tables in the dev DB since if the publish process drops and recreates tables, I will loose my prod data snapshot.
What is the right development process to follow in SQL Server Database Project?
Think of the source database (in your case, your database project) as being the "to be" state after deployment. When a deployment is initiated, the executable (SqlPackage.exe) compares the source with the target and generates a difference/delta script to make the target look like the source. This is why we no longer have to specify CREATE or ALTER; the tool figures it out. To answer your question about ongoing development, you can develop either way. You can develop in the project files and publish them to a common Dev database (say, if you're on a team), or you can develop in the database with tools like SQL Server Management Studio (SSMS) and synchronize with the project files with a schema compare (I use the latter technique because I like SSMS).
For deployment, you'll have to have SSDT installed on the machine from which you execute the deployment (SSDT ships with SQL Server 2012 and later; I don't know about SQL Server 2008). You can create scripts to simplify deployment. You'll essentially call SqlPackage.exe (it lives in x:\Program Files (x86)\Microsoft SQL Server\nnn\DAC\bin) with an action and a source. I use Publish Profiles as well to take care of most command properties. So an example deployment might look like this:
SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml
For more information:
SQL Server Data Tools Documentation
http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx
SqlPackage.exe Documentation
http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx
Make changes inside the VS DB project.
Deploy changes to localDB to test
Publish the database to your production server. I prefer to use Schema Compare to do this manually, but you can also publish the project via the right click --> publish menu (which will also create a publishing profile), or using command line arguments. The publish process won't drop and create tables (unless you tell it to drop & recreate the entire db).
Alternatively, in the project settings you can change the connection string to point to your production server (as pointed out in the comment). However, I recommend against this, as it will then attempt to publish to the production server every time you run a local build (F5).