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
Related
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.
I have a DB project which relies on SQL Server Database tools. I am trying to work on it on a Mac. The rest of the project is in .NET Core so that all works well. The database project throws an error on dotnet restore
/Users/mborozdin/src/ethos/FileRepository/src/FileRepository.Database/FileRepository.Database.sqlproj(63,3): error MSB4019: The imported project "/usr/local/share/dotnet/sdk/2.1.4/Microsoft/VisualStudio/v10.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Is there an alternative to SSDT which seems to be only available on Windows?
When you develop on the Mac,
You will put your SQL Server on the docker or Virtual Machine.
In other to connect, You need SQL Operations Studio for the Mac
Download Link
Is there an alternative to SSDT which seems to be only available on Windows?
The alternative is Azure Data Studio. As for:
SQL Database Projects extension
The SQL Database Projects extension brings project-based database development, well-known in SQL Server Data Tools (SSDT), to the cross-platform Azure Data Studio experience. From this early insiders release you can create, build, and publish a project from scratch or an existing database.
https://github.com/microsoft/azuredatastudio/issues/11105
From my understanding when extracting a sql database as a dacpac it includes the data structure with views/procs etc but no data.
a bacpac includes the structure and data but cannot be upgraded.
I read some where that dacpacs can include data now but I cannot find anywhere that shows how to do that. Is this possible?
Yes, it is possible! Easy way to include data in DACPAC is to use SQL Server Database project in Visual Studio:
Add data to post-deployment script (INSERT command etc.).
Build the project - it gaves you a DACPAC file.
Go to SQL Server Management Studio.
Execute Databases -> Deploy Data-tier application command:
Now you have a new database with data from a single DACPAC file!
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).
How do I allow an SSIS package to consume a Visual Studio 2005 or 2008 Database project which houses the creation scripts for the tables and other objects (note: this is not Visual Studio Database Edition - just Pro with Business Intelligence)?
The idea is to use this to recreate my test instance by building the schema from source safe and the data from prod.
I have access to both VS2005 and 2008 Pro and this is hitting Sql Server 2005 for both Prod and Test.
The short answer is, you cannot "allow an ssis package to consume a VS 2005 or 2008 db project". I am not sure why you want to use SSIS to run the create scripts. You can run the scripts from sqlcmd utility.
If you still want to use SSIS, this is what I would do:
create a deployment script (VS for DB Pro can do that)
create a package
in your control flow, use Execute Process Task and configure it to run sqlcmd with the script file as your input
You can call the scripts in the DB project through Execute SQL tasks in the SSIS package. However, there's not a direct way to consume them.