I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity
Related
Hello we have some SSIS packages with XML file configurations. Basically we configure the database connection, password, etc. to run the packages in different environment (Production vs. Testing). We use a 3rd party software to run our SSIS packages on target SQL servers. The packages run fine on our Testing environment, however fail miserably on Production server. The difference is SQL server on testing is vs. 2016, while on Production only 2012.
There are various error messages on why they fail on production, some of them about "Failed to load at least one of the configuration entries for the package..". And then there are some that cannot login to the database connection provided in the XML files, even though the info is 100% correct.
Does anyone know if XML config file is not supported in SQL 2012?
You really shouldn't be going from a test environment that's a different version than your production environment, it will only lead to more headache in the future.
If you can't upgrade production then I'd suggest getting another test system on the same version as production.
That being said...
The functionality is there in 2012, but the format probably isn't the same.
You need to set the TargetServerVersion to SQL Server 2012 in Visual Studio under Project > Properties and build the project again.
Project Properties
I'm using Visual Studio 2017 and TFS 2015 to create an SSDT project and deploy the DACPAC via TFS.
If I test the project in Visual Studio by publishing a profile, I'm able to view all the changes to the destination database (ex. Dropping Tables, etc) in the "Messages" tab.
I'm not seeing that same kind of output when I publish the DACPAC through TFS. There are timestamps when Deployment has started and finished, but no information on what is actually modified in the database.
Is there anywhere I can view a log of database changes that occurred when a DACPAC was published?
EDIT:
I'm using a WinRM - SQL Server DB Deployment task in TFS Release Management to deploy the DACPAC.
You could add a command line task to use SqlPackage.exe tool to generate a difference report between database. The syntax is:
/Action:DeployReport /SourceFile:$dacpac-path /TargetConnectionString:$constr /OutputPath:$reportoutputfilepath
Useful links:
https://msdn.microsoft.com/en-us/hh550080(v=vs.103).aspx
https://www.francoisdelport.com/2016/06/continuous-deployment-of-databases-part-2-sqlpackage-exe/
There are several artifacts generated when you run deployment:
DeploymentReport_X.txt --> This one has the steps performed
your_project_name.publish.sql --> This is the actual script executed on source
We have a sqlproj that targets SQL 2014 locally. The build and publish work as expected from Visual Studio.
Now we are trying to build and deploy the database project to Azure Database v12 using VS Online. We are getting errors stating the SSDT targets the wrong database. This makes sense as Azure Database and SQL 2014 surpport different features and produce different warnings/errors. Every article/post we have found online shows how to change the target platform from the GUI at design time.
Our assumption is the platform can be targeted at build time, same as changing the target platform of a class library. However we are not able to locate a list of available arguments for a sqlproj targetplatform.
Does anyone have a link or know the key=value property to set for the VS Online build parameters?
Thank you
The value is stored in DSP property of project, so you can specify /p:DSP=Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider MSBuild argument in Visual Studio Build task.
As long as everything in your project can be deployed then:
/p:AllowIncompatiblePlatform=true
I'm running some load tests using Visual Studio 2010. I haven't been able to figure out how to set where the test results are saved, and it seems that I have no test results to browse once the test runs.
I have the general idea that you're supposed to supply a SQL connection string specifying a SQL server with some tables set up on it.
Where do I set the connection string for local test runs? Is it possible to configure VS2k10 to save my test results to a file locally?
Please note that local SQL databases such as SQL Express are specifically forbidden in my environment.
If you find yourself in a situation where you didn't setup the database to store the test results from the VS 2010 Load Tester, the following will help.
The default install of VS 2010, won't have the Microsoft Visual Studio Test Controller 2010 tool.
To create the necessary tables to store the test results, all you need to do is run the loadtestresultsrepository.sql script against your database.
You'll find this script at:
x86 - C:\Program Files\Microsoft Visual Studio 10\Common7\IDE
x64 - C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Taken from:
MSDN: How to: Create a Load Test Results Repository Using SQL
Visual Studio strictly requires SQL Server for the load test store. If you don't have a SQL Server database, you cannot save test run data. All you can do is browse the result immediately after a test run, and perhaps copy-and-paste the test details into Excel. After you close the result, it's gone for good.
However, the database does not have to be on your local machine. Is there any chance you can get access to SQL Server somewhere else on your network?
You have to run "Microsoft Visual Studio Test Controller 2010 Configuration Tool" (found in Visual Studio start menu folder) to configure the database before use.
Setting the connection string is done in Test (menu) > Manage Test Controllers. This dialog allows you to select the Controller (or 'Local - No controller' for local tests) and also allows you to set the connection string to the load test results store.
Best practices or tools for installing a SQL Server database
I have a SQL Server database designed with the SQL Server GUI database editor/Visual Studio.
What is the best way to "install" that database on other systems. Said another way how should I ship this thing?
I know I can save the scripts and set the primary/foreign keys with T-SQL but I suspect their is something better. I guess you could have people restore from backup but that does not seem very professional.
What other choices are there and what are the pluses and minuses?
For it to look professional make a small setup program.
You currently have sql scripts that you use to create your db.
Make yourself a small xml file that contains the path to your scripts.
Create a small c# library that will connect to the db server, and run those scripts.
You can test this outside of the setup, in visual studio, then add it to the setup like this.
To do this from your setup all you have to do is put the xml file in a component so it is deployed,
And create a custom action in your setup, that will call your C# lib, read the xml and run the scripts on the sql server to create your db.
Also, from a setup program it's easy to set a registry key to identify the version of the your db that you just installed.
The minuses and pluses: It's a bit of work to start with, but with this you'll have all the ground work done to handle upgrades automatically later on, to do so, just add an upgradeScript section to your xml, an attribute called version for each upgrade script, and simply compare it against the version of the db you have save in the registry. The advantage is this way it can easily scale with your project.
My previous answer is mostly to keep full control on the deployment and upgrades.
I have searched for more built-in and streamlined solution that goes along with the DB designer mode you have used.
I found that in the version Studio 2005 Team Edition for Database Professionals of visual studio there might be deployment features.
Build and Deployment
You've seen that you can generate a
T-SQL update script manually via the
Schema Comparison tool. However, as
part of the build process, DB Pro
edition can generate a complete script
for deploying your database project.
This deployment script can do either a
complete build or an incremental
update. The build process can even
consolidate all of your pre- and
post-deployment scripts into one
complete deployment script. You can
deploy the script via the Build |
Deploy Selection command right from
within Visual Studio 2005. Under
project properties, you will find a
number of options to control and
adjust the build process. The Build
tab contains the core settings, such
as Target connection, Target database
name, and Block incremental deployment
if data loss might occur. You'll note
there is also a Build Events tab that
you can use to type pre- or post-build
event commands. DB Pro edition uses
MSBuild for its build process and
supports integration with Team Build
if you're using Team Foundation
Server.