How to generate 1 click deployment for SQL Scripts across environments?
We have bunch of scripts which can be Alter Stored Procedure , Insert scripts for data configuration which are deployed periodically. At this moment, we are deploying the scripts manually executing the scripts.
Right now, we are planning for one click deployment which will automatically deploy the scripts across the environments.
To my mind use SQL Server Database Project in Microsoft Visual Studio. You can develop all database objects like tables, view, functions, stored procedure and every script. And also import database schema from existing database. You can provide code for post deploy and every data configurations.
some benefits:
version and source control
develop all database objects
easy and automated deployment
and more benefits...
How to: Create a New Database Project
Related
I work for a customer who has his own database management team and I need to deploy my new web application version within a SQL Server 2008 script (I am not in position to execute any actions on their systems). I can't back up myself their database and I'm not sure they'll do it so if I delete all data it's gonna be terrible.
Therefore, I'm looking for a solution to back-up if possible the database, extract the existing datas, execute the new statements of my script, and re-include the datas saved in the database.
It is possible to do this in a SQL server script ?
More generally, how can I safely update schemas and datas of a SQL Server database within a script without losing all data inside ?
PS :
Currently, I'm using in the dev environment the initial database schema and the newest. So, I use Visual Studio 2012 with Data Tools to make Schema comparison and generate the update script.
You start with a copy of the database schema with sample data against which you can develop and test.
Then you write scripts (perhaps with the aid of a tool like SSDT) that updates the schema to be compatible with the new version of your application, retaining the data in the database.
You deliver these tested schema modification scripts along with the new version of your application for the customer's administrators to test and apply to the target database as part of the application upgrade.
I'm looking for a way to duplicate an existing database, tables and data onto a different development machine. Using SQL server 2008;
I have several tools i usually use for duplicating databases or i just restore a database dump, but i cannot use any of these. I have no direct access to the database machine i can logon via SQL enterprise manager and run queries stored procedures etc. But i have no access to the file system so i'm unable to create or copy a database dump. I cannot install or connect any tools to the database as i have to logon via a remote desktop. I also only have access to copy text files on and off the network.
I would like to run a script to generate a script to create the tables, views stored procedures etc and a script to populate the tables with some data.
I need to create a test environment so i can run tests and develop new features without affecting the live DB.
Assuming you have access to the database via SSMS, this is the approach I would take, though it could be time consuming:
Right click on the Database
Hover 'Tasks'
Hover 'Generate Scripts' and complete the process, it's self explanatory.
And from there it will generate a script for the Database architecture. This is the quick portion.
Next download Visual Studio and get the Integration Services add on. Using SSIS packages you'll be able to select all data from each source table/database and then insert the data into the destination table/database. Hope this helps you get on the right path.
I am trying to implement the CI/CD for ReadyRoll. For the release portion I am using an Azure SQL Server so I have specified the server name, db name and cred there. However, I am not sure what details do I give for the build component when creating the shadow db. I thought they were the same but then I get an error saying that its trying to create a db in my azure sql server and it fails because there's already a db with that name there. This led me to think I am supplying the wrong values but I am not sure what is that I am to supply.
ReadyRoll maintains two databases:
•Target database
This is the development database or sandbox that you use for
debugging and to edit schema objects (e.g. using SSMS). When you
deploy, ReadyRoll executes your migration scripts against this
database to upgrade it. You shouldn't drop the target database from
your SQL Server instance.
•Shadow database
This is an exact copy of your database schema created automatically
from your project scripts (001.sql, 002.sql, 003.sql, etc). It's
created every time you use the ReadyRoll DbSync tool to view pending
changes or import. The shadow database is used by the SQL Compare
engine (that powers ReadyRoll) as the base from which to generate a
new migration script. It is safe to drop the database at any time.
More information: Target and shadow databases
You can specify these arguments for shadow database: ShadowServer, ShadowUserName, ShadowPassword, ShadowDatabase. (You also can just specify target database)
More information: Shadow database
The sample for MSBuild Arguments of Visual Studio Build task:
/p:TargetServer=XXX.database.windows.net /p:TargetUsername=XXX /p:TargetPassword=XXX /p:ShadowServer=XXX /p:TargetDatabase=XXX /p:GenerateSqlPackage=True /p:SkipDriftAnalysis=True /p:ShadowUserName=XXX /p:ShadowPassword=XXX /p:DBDeployOnBuild=True
Our company is in the process of adapting TFS for source repository and project management. I am in charge of database part of the project. We are using SQL Server 2008 R2, Visual Studio 2012 and TFS Online. We have a database that is used by several of our applications. So far I have been the only one handling any change to this database. As the company is expending we are going to have multiple dev teams. So I am planning to save the database as as SSDT project to TFS.
At the moment I am maintaining my database like the following:
I have separate folders for UDFs, Stored Procedures, and Config.
Under these folders I have subfolders for each objects. For example, for stored procedures I have subfolders for each stored procedure which contains the SQL script to create the SP. The config folder contains any script similar to SSDT's post deployment script (for example, populating static data).
The SQL script contains code to drop the procedure and create it.
I have a c# app to concatenate all the SQL files into one single SQL file. Let's call it the FINAL script. When creating FINAL script I can specify version number which adds an update statement to update the version table on the database.
FINAL script is made available for customers to download and execute on the database. So the script mainly contains any add/edit to SPs, UDFs, and static data. It does not touch any existing data (data entered by user) in most cases.
As a newbie to TFS and SSDT I am not exactly sure how this can be done using SSDT/TFS or if there is better way of doing something similar. So far what I have understood about SSDT and TFS is:
I can import an existing database to SSDT project.
This will create scripts for all objects including tables.
I can easily do a publish of the database to a local server or to a server I have access to.
Things that seem confusing so far:
How do I supply clients with my latest update script? I am thinking of manually including the FINAL script to the SSDT project but there must be better way of doing it.
How do I publish the changes to a copy of the database without the loss of any user-entered data? My guess is when publishing the tables get created. I can take care of the static data but I am not sure how to handle data entered by users.
May be there is something fundamentally wrong in my understanding of this whole thing. That is why I am here... :)
You want to pull your DB into a SQL Project. Maintain all of your changes there. This tells your system what the schema of your database should be. From there, I'd generate the dacpac files (through building the project) and provide those to your clients along with having them install the SSDT tools that include SQLPackage. They can run SQLPackage to make changes to their database to handle the schema changes automatically. This will bring their database in line with your schema, no matter how far off it might be.
I'd also create a publish profile for them to use. This lets you control some of the settings.
You can choose to not drop any objects not in your project
You can choose to ignore users/permissions
You can set an option to not allow changes if there would be data loss.
You can wrap everything in a transaction so a failed update rolls back
If you give them a batch file to run, you can specify an output file or a Diff report, or have them generate their own script to do the update.
I blogged about this at http://schottsql.blogspot.com/2013/10/all-ssdt-articles.html
(or http://schottsql.blogspot.com/search/label/SSDT if that doesn't work well). That will take you through some basics of why you might want to use SQL Projects, creating them, maintaining them, and publishing the changes to an existing database.
hope that everybody here is OK.
We are using VS 2008 as development tool, TFS 2008 as version control as well as build automation. Some of our developer use dbpro for databases changes and some use SQL Server management studio.
I am trying to automate build for Web Application built using C# and VB.Net.
Our scenario is such that we have a central database to which our web application connects.
Whenever we supply our clients with a new functionality or a bug fix, we supply them incremental builds.
The SQL script is checked into source control for every incremental build when they have made and tested there changes on our central DB Server.
I want to generate Differential script that can be run at the client as an incremental update script. Now to come about it is a problem. Sometimes our developers tend to forget the database change-sets and the script in the source control is missing an SP or a two.
Also, sometimes we need to insert default data into some of the tables that have strict stringent values and not test values. Like a table that contains Services provided by the panel, we add a new service name, signature, credentials and service address, etc etc in the ServiceTable. Besides this many other tables may have test data that may not be needed.
If we use DataCompare, it will generate changeset for required data (important for client to enable certain services) and our test data that was added to the database as a result of our testing of the functionality or bug fix.
Currently i am using SQLSchemaCompareTask (from Visual Studio 2008 Team Database Professional Power Tools API) in the TFSBuild.proj file of the build definition for TFS 2008.
Using SQLSchemaCompareTask, the script generated contains database names like [dbo]. etc which are not desired as the script fails when run against SQL Server 2000 databses (Some of our client still use SQL Server 2000) databases as teh backend of the application.
Also default data can't be generated by this process.
To overcome this problem, i have to come up with a solution that can compare databases and generate script automatically that does not have to be manually reviewed again before being sent to the client.
Please suggest effective methodology of such SQL script generation and suggest whether two different databases may be used or something ? Is there any toolkit or api that can enable build automation for SQL Server databases?
Thank you all.
Regards
Steve
Try to use SQL Examiner Suite for this:
http://www.sqlaccessories.com/SQL_Examiner_Suite/
The tool compares both schema and data and produces synchronization scrips (or differentials scripts). You can automate script creation with supplied command-line tool.
Rather than collating many individual change set scripts (and therefore occasionally missing objects out), why not use schema compare and data compare to create a single script from your database project using a database equivalent to your client's on the target? This should create a script tailored to their requirements.
In data compare you can exclude test data records that you don't want pushed to your client by unchecking them in the lower grid.