Does anyone know How to configure Visual Studio 2012 Database Project to Build a deployment .sql file package.
I'm attempting to not have to use the .dacpac as my only deployment option.
e.g. generate a .sql file of all database schema alters.
If you're trying to do this automatically, you'll want to use the SQLPackage command to generate a script. If you want to do this within the IDE, publish the database and choose the option to generate a script instead of publishing the changes.
I'll usually build the project first with msbuild. That will generate a dacpac against which I can run the SQLPackage command.
My batch file looks something like this:
msbuild .\MyDB\MyDB.sqlproj /t:build /p:Configuration="Local"
sqlpackage /a:DeployReport /tsn:FTPROD /sf:.\MyDB\sql\Local\MyDB.dacpac /pr:.\MyDB\Publish\Production.publish.xml /op:.\Release\MyDB-Production.xml
sqlpackage /a:script /tsn:DBServer /sf:.\MyDB\sql\Local\MyDB.dacpac /pr:.\MyDB\Publish\Production.publish.xml /op:.\Release\MyDB-Production.sql
The first line builds the project. The second creates a deploy report so I can easily see what's going to be changed. The last generates the script. Your paths may vary so you'll need to tweak as appropriate for your environment. You'll need to be able to access the database against which the script will be run in order to generate the script.
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.
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
I am writing a wix installer and I have used it to create a sql database.
We have a custom command line tool that we need to run to populate the database with its schema and data, the tool requires sql scripts to be included, we have quite a few and they are organised into various directories.
Is it possible to include these files in the installer and then run the command line tool against these files without having to copy these files to the install target dir.
I'm thinking perhaps I will have to copy these files to temp and then after install is finished clean them up, is there a better way?
You can create an msi custom action and embed sql scripts as resources within the dll itself.
Then schedule your custom action to run the exe on those sql scripts.
The msi engine will automatically extract and cleanup your custom action binaries.
I'm just trying to understand SSIS packages a bit better and how they are deployed. Correct me I'm wrong but for any deployment, I believe there needs to be at least two files a .SSISDeploymentManifest and a .dtsx. The .SSISDeploymentManifest acts as the equivalent windows installer package which points to the .dtsx. The dtsx is the actual package of "stuff" that is referenced as an external file some how when you run the installer. When you install it, the package gets added to a list of ssis packages for that instance.
My further questions:
If i wanted to keep previous version of the same package, can I just copy the bin directories with the two above files and keep separately should I need to roll back to a previous package?
Where are these packages installed to? How does SSIS know where the packagess are?
Correct me I'm wrong but for any deployment, I believe there needs to
be at least two files a .SSISDeploymentManifest and a .dtsx. The
.SSISDeploymentManifest acts as the equivalent windows installer
package which points to the .dtsx. The dtsx is the actual package of
"stuff" that is referenced as an external file some how when you run
the installer. When you install it, the package gets added to a list
of ssis packages for that instance.
Your assumptions are mostly correct. You don't need the deployment manifest, but it can be handy. Also, you don't need to deploy to the SQL Server instance. You have the option to deploy to the file system as well. I'll explain both below.
Regarding your 1st question:
Version Control:
Make sure you're developing and checking in your dtsx packages via visual studio. Label your releases in sourcesafe or whatever version control you're using. If you are checking in and labeling, then you should be able to easily roll back to a previous version. As you mention, you also can just save a copy of your old bin directory but naturally put them in dated subfolders or something. However, this does not take the place of proper version control.
Regarding your 2nd question:
Deployment:
As the other poster states, you first have a decision to make:
a) Deploy packages to the file system
b) Deploy packages to MSDB
There are benefits to each, and everyone has their preference. I have used both, but I prefer the filesystem because it's more transparent, however there is more to maintain.
See this post for much more on this: http://blogs.conchango.com/jamiethomson/archive/2006/01/05/SSIS_3A00_-Common-folder-structure.aspx
The code is in the dtsx package. Generally,in order to make your packages portable you also abstract your connection strings and other configurable information into a config file (.dtsconfig) or environment variable (no file needed). See BOL to learn more about configuration.
The manifest file contains metadata about which dtsx and config files to install. If you open one, you'll see it's a simple readable xml file.
The manifest file makes it easy to hand over to a DBA to deploy (ask them to double-click the manifest file and follow directions, but they'll need instructions.
To me, the manifest file is more useful for deploying to SQL Server than to the file system. Really, all it does is make a copy of the dtsx and config files and puts them where you tell it. You could just as easily instruct the DBA to copy your dtsx files to a common folder on the server, and the config files to another folder on the same server.
Then when you schedule your jobs using SQL Agent, you specify that you're going to run an SSIS package that is stored on the file system and browse to where it's located. If you're using configurations, then there's a tab to specify where the config file is located.
There is so much to know about configuring/deployment/versioning of SSIS packages. But hopefully this will get you started on the right path.
When you export your DTS packages using the Import/Export Wizard in SQL Server you have the option of saving them to SQL Server or locally on the file system.
Regarding the versions of your SSIS packages, you need to query SSISDB to extract the version numbers. It's annoying this kind of info isn't shown directly in the Management Studio but, until it is, someone may find this useful:
SELECT prj.[name] as Project
,pkg.[name] as Package
,pkg.[version_major]
,pkg.[version_minor]
,pkg.[version_build]
FROM [SSISDB].[internal].[packages] as pkg
JOIN [SSISDB].[internal].[projects] as prj
ON pkg.[project_id] = prj.[project_id]
ORDER BY prj.[name]
Is it possible to somehow use a .bat file to script the schema and/or content of a SQL Server database?
I can do this via the wizard, but would like to streamline the creation of this file for source control purposes.
I would like to avoid the use of 3rd party tools, just limiting myself to the tools that come with SQL Server.
There is a free tool called SubCommander that is a part of the open source SubSonic software. I have successfully used this tool myself to create both schema and data "dumps" each night.
You can script out your schema and
data (and then version it in your
favorite source control system) using
SubCommander. Simply use the command
"version" and tell SubCommander where
to put the data:
sonic.exe version /out Scripts
This will output a script file (.sql)
to the local scripts directory of your
project
You can also try using the Microsoft SQL Server Database Publishing wizard, although i am not sure that you can use it in a bat file.