I tried to generate the script by query because I want create easily and same settings. I checked MSdoc but there is no method.
I use SSMS v17.6, SQLServer2016(SP2) on WindowsServer2012 R2 Standard.
By the GUI, DB right click=>Task=>generate scripts=>select database objects and set some settings.
I want to generate by query.
You can follow below steps to automate the creation of a database.
First export the database as a dapac using Export Data Tier Application
Install SQLPackage.exe in the environment where you are planning to carry out the deployment. You can download sqlpackage.exe download path . It will be used to automate the generation of scripts from DACPAC.
Once you have the DACPAC of the database, you can publish the same to any environment. The caveat is, Sqlpackage.exe generates incremental script, comparing against the target datatbase. If you want complete CREATE script, then you can point against any empty database or system database like master to generate incremental CREATE scripts(here it will be complete database script, as target is empty database). The generated script will be present in the output path (here, it is C:\temp)
Note: we are setting parameter (DropObjectsNotInSource to false), to avoid generation of drop objects of the target database, which are
missing in source DACPAC.
"<Path>\SqlPackage.exe"
/Action:script
/SourceFile:“<Path>\Database.dacpac”
/TargetDatabaseName:master
/TargetServerName:"localhost"
/OutputPath:C:\temp
/p:DropObjectsNotInSource:false
UPDATE
I see that, now there is a tool mssql-scripter(currently in preview) to carry out the same activity of Generate Scripts wizard of SQL Server Management Studio. You can see about the tool here: https://github.com/Microsoft/mssql-scripter
Related
I am trying to create a database from my TFS project using SQL Compare.
Currently we compare our Database project to a CI database using the Compare tool in Visual Studio however, I have been asked to make this eventually run as a build step as part of the automated deployment.
Problem* SQL Compare will not recognize the database assembly file generated within visual studio. Therefore some computed columns that use clr functions fail on deployment.
I had success using SQL Compare to script a previously scripted Database to a 'Scripts Folder'. Next I pointed my SQL Compare left side to that new 'Scripts Folder' and right side at a new Database and the Assembly file was detected on the left side.
I have then tried copying the database assembly file to the visual studio database project location with no luck.
I unpacked the generated file 'Database.xxx.dacpac' file to a folder and set my Left side compare in SQL Compare to that. SQL Compare complains about "Scripts folder found with missing metadata file". There were other errors after I hit 'Compare' but I ignored them. However my assembly file showed up!
Is this supposed to be the correct process? assuming I remove all the warnings?
I expect to be able to compare my database project file in visual studio to a fresh database and update it within SQL Compare
Right click on your Database project file in the Solution Explorer
Go to build - and look up the location of 'Build Output Path' find the 'database.dacpac' file
Option A: double click and unpack the .dacpac file. In SQL Compare use option 'Script Folder' and use that newly created folder as a source, you can then create a database from your visual studio database project. SQL Compare - using DACPAC file
Option B: Use command line and SSMS application sqlpackage.exe to create database directly from the dacpac file without extracting.DACPAC Deployment using command line
Option C: Right click on database you want to upgrade in SSMS - and click on Tasks->'Upgrade Data-tier Application'. Use the DACPAC file as the source.
When I extract a data-tier application from a Microsoft Azure SQL database that has a Master Key, I was unable to import it into SQL server on my local PC.
You will find others had this issue here: SSMS 2016 Error Importing Azure SQL v12 bacpac: master keys without password not supported
However the steps provided as the answer did not work on my installation.
Steps are
1. Disable auditing on the server (or database)
2. Drop the database master key with DROP MASTER KEY command.
Microsoft Tech Support verified this solution did not work on my installation of SQL Server and after actually taking remote control of my PC and trouble shooting, they were unable to determine why this was occurring.
I needed to find a way to remove the Master Key from the bacpac file. I have a Powershell script to remove the Master Key from the BACPAC file but it requires extracting, renaming files and running scripts from Windows Powershell to get the db imported.
Does anyone have a program or set of scripts which would automate the process of removing the Master Key and importing a SQL DB from Azure with a single command?
I am new to this forum. Please do not be harsh with this post. I am trying to do the best I can to help others to save the many hours I spent coming up with this.
I have cobbled together a T-SQL script which calls a Windows Powershell script (also cobbled from multiple sources) to extract a data-tier application (database) from Microsoft Azure SQL database and import it into a database on my local SQL Server by running ONE command. Over the months I found some of the code that is in my scripts from other blogs etc. I am not able to provide the credit due to those folks as I didn't keep track of where I got the info. If you are reading this and you see your code, please take credit. I apologize for not being able to give you the credit for your work.
There may be configuration settings on your PC and your local SQL server that need adjustments as this entire solution requires pretty much full access to your computer. If you run into trouble with compatibility, let me know and I will do the best I can to let you know how my system is configured in case it will help you.
I am using Windows 10 Pro and Microsoft SQL Server Developer (64-bit) v12.0.5207.0
I have placed the two files that do all the work on GitHub here: https://github.com/Wingloader/Auto-Azure-BACPAC-Download.git
GetNewBacpac-forGitHub.sql
GetAzureDB-forGitHub.ps1
WARNING: The Powershell script file will store your SQL sa password and your Azure SQL login in clear text!
If you don't want to do this, don't use this solution.
My computer is owned and controlled solely by me so I am able to open up the security in my system and I am willing to assume the responsibility of safeguarding it.
The basic steps of my solution are are accomplished as follows: (steps 1 and 2 are optional as I like to keep a version of the DB I am working with as of the point in time I pull down a clean production copy of my Azure DB)
Back up the current DB as MyLocalDB.bak.
Restore that backup from step 1 to a new DB with the previous day stamped at the end of the DB name (e.g., MyLocalDB20171231)
Delete the original MyLocalDB database (needed so we can recreate the DB with the original name later on)
Pull down the production database from Azure and create a new database with the name MyLocalDB.
The original DB is deleted in step 3 so that the restored DB can use the original name (important when you have data connections referring to that DB name)
In Step 4, the work of extracting the data-tier application DB from Azure is initiated by this line in the T-SQL:
EXEC MASTER..xp_cmdshell '%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -File C:\Git\GetUpdatedAzureDB\GetAzureDB.ps1"'
The Powershell script does the following:
The target for the extract is a file named today.bacpac (hardcoded). The first thing to do is delete that file if it already exists.
Extract the DB from Azure into the today.bacpac file.
Note: my DB on Azure has a Master Key for encryption. This will need to be removed from the files prior to importing the bacpac file into your local DB or it will fail (this may not be required in SQL 2017 according to my previous conversations with MS Support). If you do not use a Master Key, you can either strip out the code that does this step or just leave it alone. It won't remove anything if it isn't there. It would just add a little overhead to the program.
Open the today.bacpac file (zip file) and remove the MasterKey node from the Origin.xml file.
Modify the Model.xml file to updates the SHA hash length. This is required in order for the file not to appear to have been tampered with when SQL opens the bacpac file.
Re-zips the files back into a new file today-patched.bacpac
Runs this line of code (from Powershell) to import the bacpac file into SQL Server
&C:\Program Files (x86)\Microsoft SQL Server\140\DAC\bin\SqlPackage.exe" /Action:Import /SourceFile:"C:\Git\GetUpdatedAzureDB\today-patched.bacpac" /TargetConnectionString:"Data Source=MyLocalSQLServer;User ID=sa; Password=MySAPassword; Initial Catalog=MyLocalDB; Integrated Security=false;"
After editing the two files to provide updated paths, usernames and passwords, run the SQL script. You do not need to edit the scripts again. You can run the SQL script again without modification and it will create a new copy of your Azure DB.
Done!
I have an SSDT project with VS2015 and using SqlPackage.exe to generate deployment scripts and incremental update scripts. The database project contains post deployment scripts. here's how I generate the main script for DB installation:
sqlpackage.exe
/a:Script
/op:"database.sql"
/sf:"database.dacpac"
/tsn:"localhost"
/tdn:"MyDbName"
/p:CommentOutSetVarDeclarations="True"
/p:ScriptDatabaseCompatibility="True"
/p:IgnoreFileAndLogFilePath="True"
/p:IgnoreFilegroupPlacement="True"
/p:ScriptFileSize="True"
/p:PopulateFilesOnFilegroups="False"
This will output database.sql file which I run with sqlcmd.exe. the script file also contains all my post deployment scripts (Insert, Update, etc..)
Once I have a new version of the database, I create incremental update script from previously taken dacpac snapshot:
sqlpackage.exe
/a:Script
/op:"%migratePath%\%database%.!build!-%version%.sql"
/sf:"%snapshotPath%\%database%.%version%.dacpac"
/tf:"%snapshotPath%\%database%.!build!.dacpac"
/tdn:"MyDbName"
/p:CommentOutSetVarDeclarations="True"
/p:AllowIncompatiblePlatform="True"
/p:IgnorePermissions="True"
/p:IgnoreRoleMembership="True"
/p:ExcludeObjectTypes=Users;Credentials;Logins;Permissions;RoleMembership;ServerRoles;ServerRoleMembership;
this works fine, however, incremental update script does not contain metadata/reference data (e.g. e.g. list of countries, states, currencies, etc.).
Is there a way to tell SqlPackage to generate incremental script that contains the table reference data as well?
We currently use TFS 2010 for our VS applications and our SQL code. For SQL we have every stored procedure stored in different text files e.g."spname.sql" and we alter these files and then apply them to the Dev server.
When it comes to testing we then do a branchcompare to compare the DEV branch to the UAT branch to get a list of the .sql files that are different.
Question is, is there a way to export out the files in the list from the dev branch so we can them apply all the SQL code that has changed to the UAT server?
(We do table alters / updates etc in a "rollout" type script).
Thanks
When you do a compare in Visual Studio (with SSDT), you can choose to create a script instead of deploying. Or you could use powershell Get-TfsItemHistory with -Version to get the file list and then use that list to get the source.
I have a Visual Studio 2010 Database project, from which I want to generate a script
that simply puts up this database to another machine. The problem is that i can't find a
solution for this.
As I started the project, I imported the shema from a database on my development pc.
The Schema Objects were generated and all tables and scripts where under 'Schema Objects -> Schemas -> dbo'. Over the time, some things changed, some where added. And by using right-click -> deploy,
the changes were made to my local database successfully.
But now I want to deploy to another machine. The problem is, that in the release folder of the project, there is only a xml dbschema file containing all tables and scripts that i can't import
with sql management studio (or i just can't find out how) and the a deployment script which is nothing more than some checks followed by the pre- and post- deployment script, but without any tables or scripts in it.
So please, how do i export the database from Visual Studio, so i can easily put it up on another machine?
Marks--
You likely have already resolved this, but I thought I should answer your questions for the benefit of others.
Yes, you can deploy from Visual Studio to different machines. You can also do it from the command line, using VSDBCMD. And you can create a WIX project to give a wizard for others to install it with.
If you can connect to the target database from your dev PC, you can deploy to it. To do this:
Select another Configuration from the Solution Configuration drop down. Normally, the Project will come with "Debug" and "Release" baked in. You can add another configuration to allow you to deploy to various targets by clicking "Configuration Manager."
Right-click your Project and select 'Properties', or simply double-click Properties under the project.
Click the Deploy tab. Notice that the Configuration: drop-down shows the same selected configuration as "active."
Change the Deploy Action to "Create a deployment script (.sql) and deploy to the database."
Next to Target Connection String, click "Edit" and use the dialog to create your deployment connection to the target database.
Fill in the Target database name, if different.
For each Deployment Configuration (e.g., Debug, Release, etc.), you will probably want a separate Deployment configuration file. If you click "New," you can create one for the current configuration. The new file will open, and you can check and uncheck important things about the deployment.
Note: If you check Always re-create the database, the script will DROP and CREATE your database. You will lose all your data on the target! Be careful what you select here. Most people leave that unchecked for a Production target. I check it for Development or Local because I want a fresh copy there.
Save your changes to the file and to Properties.
To deploy to the target, be sure to select the correct Configuration. Click Build/Deploy [My Database Name]. You probably should experiment with this so you are familiar with how it works before trying it on a live environment.
Good practices: build a similar environment to production ("Staging") and deploy there first, to test the deployment, and always back up the database before deploying, in case something goes wrong.
For more info, please see:
Working with Database Projects
Walkthrough: Put an Existing Database Schema Under Version Control
Visual Studio 2010 SQL Server Database Projects
Is it's possible to point your Visual Studio to your new target database? 1. Properties of your Database project, Deploy tab, set the fields in Target Database Settings.
Now when you generate a deploy script, the resulting SQL file will be the various CREATe / ALTER / DROP etc that will align the target database with your schema.
You could always create an empty database and then do a schema compare in Visual Studio between your database project and the new empty database. You can amend the generated schema update script to also create the database (since the script will be to update an existing empty database)