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.
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
Just to make it clear, my objective is to reproduce an environment similar to a TFS 2013 that someone backup from.
The backup (full) was made manually from SQL cause TFS is reproducing an error in the attempt of it and I'm trying to fix this error in a test environment.
Which way should I use SQL to backup it?
How should i restore and map TFS in the new server to understand it?
Note: The backup was created by an user that does not exist on the test machine;
Note²: I have the .bak's files (Tfs_configuration, Tfs_DefaultCollection and Tfs_Warehouse).
I can paste the error log of TFS if needed.
The whole process is well documented, it's easiest when you have a Full TFS backup from the Administration Console, that way you're sure to have all the databases in their right state.
The process to follow is quite extensive, make sure you follow each of the steps. If the environment you're restoring from didn't have the backup feature built-in (it was added in one of the update packs), then you can get it by installing the Team Foundation Server Power Tools on the Application Tier server.
To update the accounts use:
https://msdn.microsoft.com/en-us/library/ms404869(v=vs.120).aspx#UpdateNetworkService
It looks like you may have all the databases required, though it's possible there are more. To restore TFS to a new environment, you need all the databases that belong to the installation.
I have a SQL Server Scripts 2012 Project with multiple SQL queries and stored procedures.
We use Team Foundation Server 2012 to manage our source code for our Visual Studio Solutions.
How can I check in a SQL Server Scripts 2012 Project into TFS? If it is not possible how can I manage source control on this and allow multiple developers access to it?
You have a few options, here are two that I have used.
1: Download the TFS 2012 MSSCCI Provider:
This plugin allows you to access TFS from Microsoft SQL Server Management Studio. So you can easily add and check in\out those ssmssln and ssmsproj files from TFS.
64bit Download - 32bit Download
Once installed, in SSMS go to Tools-> Options -> Source Control to select the plugin.
If you don't see it then you probably need to install the other bit version.
After you have selected the plugin in the options window of SSMS, you will have a new menu option under "File" that will allow you to Add\Open\Change items in TFS from Sql Management Studio.
To add your Scripts solution using the MSSCCI plugin:
Open the project in SSMS, go to File -> Source Control -> Add Solution to Source Control
2. Add through VS using the "Add files to Source Control"
See here: To add a file that is not in a solution to version control
I'm not quite sure why it would be a challenge to add the sql server scripts to TFS just as any other file in your visual studio solution. I've done this in a lot of projects with great success.
What is a challenge with databases though is to find a good strategy to handle branches and database versioning. I recommend that you have a look at Entity Framework Code First Migrations which handles this very nicely. Another approach is to use Chuck Norris Round house which is a more script based solution:
RoundHouse
https://code.google.com/p/roundhouse/
Code First Migrations.
http://msdn.microsoft.com/en-us/data/jj591621.aspx
If you start from scratch I would recommend the Code First Migrations approach, but if you allready have a lot of .sql files the second can work very well.
The latest versions of MSSCCI still don't seem to work with SSMS 2012 - you'll need an older 32 bit version, here: http://visualstudiogallery.msdn.microsoft.com/en-us/bce06506-be38-47a1-9f29-d3937d3d88d6
Once this is installed you'll be able to see the "Team Foundation Server MSSCCI Provider" in the SSMS Source Control Plug-In selection.
The scenario:
I have written a software application that includes an installer, that is to be used by Mr Layman to install the system on to a single computer.
The system is a simple C# winforms application with an SQL Express database. The target machine would be a standard installation of Windows XP with SQL Express and .NET 3.5 installed.
I am able to create the installer for the winforms app, that would check the version, create all the directories and copy over all the necessary executable's etc. I have also an SQL script that will create the database and populate it with the necessary data. However I do not know how to go about creating a stand alone installer for the database on the target machine.
I have an SQL script that will create the database etc, but how do I make the installer run this script? I've had a google and I don't really know what I'm looking for, can someone point me in the right direction please.
Thank you in advance.
Create a custom action in the installer project that will take your SQL script and run it against the database. Here's an MSDN link that covers the basics.
An installer which runs SQL scripts can be created in 2 ways:
The very hard way:
create an installation with custom dialogs which retrieve the SQL connection information
save that information somehow (in an MSI package you can use installer properties)
write a custom action which uses that information to connect to SQL Server and run your script
The easy way:
use a setup authoring tool which supports SQL scripts
If you want a free solution, I recommend WiX. It has a steep learning curve, but it does what you need.
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