I am needing to move all of my stored procedures into TFS 2012. I was wondering what the best/fastest way to accomplish this is. I am using SQL Server 2012.
Our suggestion would be to use the SQL Server Data Tools (SSDT) and create a database schema change management project in Visual Studio that you can then check-in to Team Foundation Server. It has quite a few benefits like being able to "compile" the schema and has tools that can be used in generating automatic change scripts for target servers (whether they are empty, test, or even production servers).
http://msdn.microsoft.com/en-us/data/tools.aspx
SSDT is definitely the way to go, It's a component of Visual Studio. There is an SSDT for database projects, and SSDT-BI for reports etc.
Create a database project in Visual Studio and add your database objects (stored procedures, views, functions, tables, schemas etc) into the project. It allows for all database objects to be stored in there (even database roles/users, certificates, keys etc).
Alternatively, you can use Visual Studio to import a database from a server. It will read your database and populate the project with all the objects from that database. It's very cool.
You can check in to TFS as you would with any other project which allows you to do versioning (with comments), attach that work to TFS tickets (if you manage your workload that way) and perform branching and merging and you can also compare different versions of the project or the project against already deployed versions.
Once you're happy with your database you can 'publish' your project up to a server of your choosing. This is a very useful method for creating code that can be deployed to multiple environments (i.e. different dev/test environments). You can also compare your project against a deployed version to see changes. For example, you could compare your project against a test environment to see what the differences are and generate a script to update the test environment to match source (or vice-versa).
SSDT is great for deployments because it calculates how to apply your database project (rather than just dropping the database and creating a new one). You can also use pre & post deployment scripts to work with data or add permissions onto your objects for example.
You can publish to a database/server, script or DACPAC (which is the format for copying your entire project/database schema and allows you to perform deployments/drift reports etc from outside of Visual Studio)
Related
We are using SQL Server 2014 with Visual Studio 2015, we have a database project and a database.
Some programmers like to update procedures on visual studio and some others from management studio.
We have an issue, if you create the db project from database, all files created, for example stored procedures are generated with CREATE in tfs, same way the sp is saved on the database. When I do schema compare, all match. If someone use visual studio for altering one sp, he needs to change the file putting ALTER, this will allow developer to update the sp in the db from visual studio.
Now if I do schema compare again from db to tfs, I will have a new object to add in tfs because in the database is with CREATE and in tfs is with ALTER.
How can I solve this issue?
If someone use visual studio for altering one sp
This is the part that doesn't really fit with the "standard" SSDT workflow. SSDT generally assumes you are going to build a project (with or without TFS) and then update the whole database at once using "publish".
If you need to deploy single objects from Visual Studio, there are a couple of options such as "Quick Deploy" from https://agilesql.club/Projects/SSDT-Dev-Pack. This extension will let you deploy a single object (of some types) without changing the CREATE to an ALTER but bear in mind that using tools like this for routine deployment gives up many of the benefits (validation etc) of using SSDT in the first place.
"If someone use visual studio for altering one sp, he needs to change the file putting ALTER, this will allow developer to update the sp in the db from visual studio."
This is where you're going wrong. You mustn't change the files in the SSDT database project from CREATE to ALTER. If you want to alter an object in a connected manner (ie, on the database) you have a couple of options:
1) Open a query window (either in SSMS or from the Server Object Explorer) and execute an ALTER (note that this ALTER just gets executed and not saved in the project). You then run Schema Compare between the database and the project and apply changes to the project. Note that this isn't the supported/preferred workflow of SSDT. Instead it is designed to be used offline by changing the CREATE files, but this model won't work in SSMS.
2) You can consider ReadyRoll, which is developed at Redgate where I work. This is a database project in Visual Studio but it supports the connected workflow, which means that developers can make changes to a dev DB in either VS or SSMS and these changes can be imported back to the database project in a mouse click. This option has the advantage of being able to use the same development methodology in VS and SSMS alike.
I have been working on a project which has a database project in it and I used to publish that database when ever I made some changes to the scripts. Now that I noticed that when I publish the database project it builds first and creates a dacpac file and then it publishes after I selects the target database. I am interested in knowing what role does that dacpac file plays in publishing the sql database.
Also I have found this thing when I was trying to read about pro's and con's about dacpac. Is it really works like that?
Link
The biggest problem with DACPACs has to do with the way a data-tier application is released to push version changes from the DAC into SQL Server. This is done by creating a new database with a temporary name, generating the new objects in the database, and then moving all the data from the existing database to the new one. After all the data has been transferred and the post-release scripts run, the existing database is dropped and the new database is given the correct name.
The dacpac file is the compiled build output of the database project. It's analogous to a .dll file built from a C# class library project. All of the information you defined in your database project about your database is stored in the dacpac file, along with information about the relationships between the objects.
When a dacpac file is published, the target database is compared to the dacpac and the tool will figure out what T-SQL to execute to make the target database match the dacpac's definition.
Regarding the article, note that the Data-Tier Application Framework that shipped with SQL Server 2008 R2 was largely rewritten/replaced for SQL Server 2012, so that article, while correct regarding that very old version of the Data-Tier Application Framework, is not correct regarding the tools available today.
The DACPAC file is a Zip file contains an XML representation of your database schema. It does not contain any table data (unless you provide pre-and-post deployment scripts). More information is available here: https://www.simple-talk.com/sql/database-delivery/microsoft-and-database-lifecycle-management-(dlm)-the-dacpac/
When a DACPAC is deployed, the receiving server compares the difference between the current schema and then updates your schema accordingly by generating a change script. However, be careful, as some changes can be very expensive (such as adding a new column in the middle of a table that already has millions of rows).
The article I linked to shows you how you can view the generated change script and see what happens. Repeated here is a snippet that does it:
"%ProgramFiles(x86)%\Microsoft SQL Server"\110\DAC\bin\sqlpackage.exe
/Action:Script
/SourceFile:MyPathAndFileToTheDacPac
/TargetConnectionString:"Server=MyTargetInstance;Database=MyTargetDatabase;Integrated Security=SSPI;"
/OutPutPath:"MyPathAndFile.sql"
Using DACPACs and Database Projects (in SSDT, but do not use SQL Server Management Studio) is the preferred way of pushing database changes now as it is less error-prone than manually redesigning tables using the table designer (which will drop-recreate-and-repopulate tables if you do things like add non-terminal columns to existing tables).
I'm not too familiar with it but played around with some database uploads myself. From what I gathered the dacpac has settings that can be used and uploaded. I found these instructions:
•To create a database project based on a dacpac, create a new SQL Server Database Project in Visual Studio. Then right-click on the project in Solution Explorer and choose "Import -> Data-tier Application (*.dacpac)" and select your dacpac. That will convert the contents of the dacpac into scripts in the project, and if you choose "Import database settings" the database options will be set based on the settings in the dacpac.
Dacpac is A data-tier application (DAC) is a logical database management entity that defines all of the SQL Server objects - like tables, views, and instance objects, including logins – associated with a user’s database. A DAC is a self-contained unit of SQL Server database deployment that enables data-tier developers and database administrators to package SQL Server objects into a portable artifact called a DAC package, also known as a DACPAC. from https://msdn.microsoft.com/en-us/library/ee210546.aspx
hope this helps...
What are advantages of using SQL Server Database Project in VS 2013?
Currently I dont use this on my project, I am generate script from SQL Server Management.
Should I move to Database Project? How complicated is?
There are many advantage of sql project.
1.Easily deployable in any conditions.
2.You can view history of db objects
3.You can maitain all db objects under on roof.
Effectively, a database project converts all of the objects in your database (table designs, stored procedures) into text files -- text files that can be searched, modified and stored in source control just like your code files. A database project also includes designers for working with these files. Visual Studio cross-references those files to give you a higher level of IntelliSense support for working with stored procedures than you'll ever get in SQL Server Management Studio.
You also get a staging database where you can make your changes before updating your production or development database and a schema comparison tool for determining, after the fact, what changes you've made. Effectively, you get an isolated database environment for trying out database changes.
I'm currently in the process of redesigning our department's source control strategy using Team Foundation Server (TFS) in regard to database objects. Essentially, we store nothing in TFS at this time. I have discovered SSDT and really enjoy their integration within Visual Studio and think it will make our transition into TFS much easier.
So, Does SSDT have the capability of generating scripts based on the delta's of my SSDT project verses what is in our server? It seems from what I have researched, I will only be able to generate an entire database script.
Requirements (Mind you, our developers do not have ddl access to production):
I cannot drop a database to re-create it
I cannot drop ALL objects like all stored procs to re-create them but only what I need
Tables will need to be altered not dropped and only what has changed
Dacpac's are out of the question
Our best option based on our environment at this time is to use scripts for updates
Our database environment is currently SQL Server 2008 R2. My SSDT version is the latest 2013 that was published in June.
Yes, if you do a publish from the project you will pretty much meet all of these requirements, though dacpacs are built as part of the process. The schema compare and pre/post deploy scripts are stored in the dacpac and the publish reads what "should" be present against what is currently in the database. It then generates a change script of all necessary changes to bring the database in line with the project.
Make sure you use the Refactor/Rename when renaming objects - that will cut down on the table drop/recreate operations. You may want to be careful with the "Drop objects not in the project" options. If you haven't been careful with making sure all objects created in your production server are in your project, you could accidentally drop something important just because someone didn't get it checked in.
There are command lines to the SQLPackage command that can generate change detail reports and scripts that you can use. The scripts need to be run through SQLCMD or in SQLCMD mode, but you can definitely produce scripts pretty easily.
I need to create an entirely new Sql Server 2008 database and want to use a Database Project in Visual Studio 2010 (Ultimate). I've created the project and added a table under the dbo schema.
The table .sql is shown only as plain text, though with colors. It has no designer, no Add Column, and no autocomplete. Existing column's properties are grayed out.
Usually, I use DB Project for nothing more than storing .sql files for source control purposes, but I'm assuming it can help me with designing the DB. Currently, it offers no such help and I think it's because I'm doing something wrong. Perhaps I need to deploy the DB to server first, or something of the such. I've looked for a Getting Started guide, but all guides I found start from importing an existing database.
Please help my understand what a DB Project can do for me and how.
Thanks,
Asaf
The whole idea of the VSTS DB is to get you set on the right path, ie. store database object definitions as .sql files, not as some fancy diagram. Any modification you do to the objects you do it by modifying the SQL definition. This way you get to do any modification to the objects, as permitted by the DDL syntax, as opposed to whatever the visual-designer-du-jour thinks you can and can't do. Not to mention the plethora of SQL code generation bugs associated with all designers out there.
The closes to a visual view is the Schema View, which shows tables, columns, indexes etc in a tree view and you can see the properties from there.
By focusing the development process and the Visual Studio project on the .sql source files, teams can cooperate on the database design using tried and tested source control methods (check-out/check-in, lock file, conflict detection and merge integration, branching etc).
the deliverable of a VSTS DB project is a the .dbschema file, which can be deployed on any server via the vsdbcmd tool. This is an intelligent deployment that does a a schema synchronization (merge of new object, modifies existing ones) and can detect and prevent data loss during deployment. By contrast, the 'classical' way of doing it (from VS Server eExplorer, or from SSMS) the deliverable was the MDF file itself, the database. This poses huge problems at deployment. The deployment of v1 is really smooth (just copy the MDF, done), but as soon as you want to release v1.1 you're stuck: you have a new MDF, but the production is running on its own MDF and does not want to replace it with yours, since it means data loss. Now you turn around and wish you have some sort of database schema version deployment story, and this is what VSTS DB does for you from day 0.
You might be better off downloading the SQL Server Management Studio for SQL Server 2008 Express - http://www.microsoft.com/downloads/details.aspx?FamilyId=C243A5AE-4BD1-4E3D-94B8-5A0F62BF7796
Using this tool you can create your database using the visual tools provided by that software. You can run your .sql script to build up the database and then visually adjust columns settings, table relationships, etc.
Once you have your database designed open up Visual Studio and open a connection to this database using the Server Explorer.
Visual Studio is ok for simple tweaks and changes to an existing database structure but for anything serious like making the database from scratch I would recommend using the Management Studio. It's free and built for that exact purpose :)