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.
Related
We are using Visual Studio 2013 with SSDT mainly for versioning t-sql code, so the sql is being developed on the dev server and then we use schema compare to transfer the scripts into visual studio (and check into Git). Before deployment (which we currently do with schema compare, too) we have to replace database and server references (with [$(database)] etc.). If we change the code in the dev server and compare again, such SQLCMD variables are lost again. (I would expect schema compare to be smart enough to retain the SQLCMD variables but I found no way to accomplish this).
The logical step is to develop sql in visual studio from the start. But so far, it has been hard to convince anybody in the team to do that. One can write sql and execute it in VS, no problem. One can also switch to SQLCMD mode and execute, all right. But when you create e.g. a view in VS, you must write down a create statement and of course this can be executed once but will yield an error when altering the view and executing the create statement again.
So my question is if anybody has some essential tips on how to do database development exclusively in Visual Studio. We were able to get the database references and all that straight, but not the development process.
I've been streamlining local database development and deployment using Visual Studio database projects for a few years now. Here are some tips.
In general...
Use local db instances: Each developer should have their own database instance installed locally. All scripts (tables, views, stored procs, etc.) should be developed in Visual Studio. Create a publish profile for deploying the project to the local db instance.
Use Publish feature: Confusingly Visual Studio provides both a Deploy and a Publish option which ultimately do the same thing. I recommend using just Publish because it's more prominent in the UI and you can create profiles to configure the deployment process for various database instances.
Keep local db up to date: When a developer makes changes in the database project and checks them in to source control then the other developers should check out these changes and republish the project to their local databases.
Create vs. Alter statements
All of your statements should be Create statements. There is no need for Alter statements or existence checks. Everything should be scripted as if you are creating the database objects for the first time. When you deploy or publish, VS will know whether to issue Alter statements for existing objects.
Data
Some ideas:
Script your data as a series of Insert statements. Include them in a post-deployment script in the database project. But this can be tedious and error-prone.
Keep a database backup that includes all of your test data. When setting up a development environment for the first time, create the database from the backup. After you make significant changes to the data, create a new backup and have your devs recreate their databases from the backup. In most cases it's ok if the backup is out of sync with the schema defined in the project -- simply republish the project (make sure to turn off the "Re-create database" setting so that only the differences are published and thus the data is not lost).
There may be 3rd party tools to do this in which case they are worth looking in to.
Create your own solution for deploying data. Mine involved the following and worked really nicely (but required a lot of time and effort!):
All data stored in XML files - 1 file per table - whose structure resembled the table
An executable to read the XML files and generate SQL merge (or insert/update) statements for each row of data and save them to a SQL script
A pre-build event in the database project to run the executable and copy the resulting SQL script to a post-deployment script in the project
Publish the project and the data will be pushed during post-deployment
Test/Production Deployments
Publish feature: You can create publish profiles for your test and production environments. However it will include your pre- and post-deployment scripts, and you won't get the versatility that the other options provide.
dacpacs: Ed Elliott covered them in his answer. Advantages: no need for Visual Studio to deploy, they can be deployed via SQL Management Studio or the command line with sqlpackage.exe, they can be easier to work with than a T-SQL deployment script.
Schema Compare: Schema compare may be good if you can use Visual Studio for your deployments and you like to double check all of the changes being deployed. You can also selectively ignore changes which is useful when you aren't lucky enough to have a development environment that completely mirrors production.
An age-old challenge. We've tried to use the data projects as they were defined through the years, but ran into several problems, including the fact that it seemed that these projects changed with every release of Visual Studio.
Now, we use the data project only to integrate with TFS for work item management and source code control. The way we do it so that we can build sprocs/views in Visual Studio is we write each script using the drop/create pattern. Our scripts also contain security (we made the mistake of using the default schema... if I could go back in time we'd segregate schemas and do schema-based role level security).
For table schema, we do schema compares to/from a versioned template database.
A typical stored proc looks like this:
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[sp_MyStoredProcedure]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[sp_MyStoredProcedure]
GO
CREATE PROCEDURE [dbo].[sp_MyStoredProcedure]
#MyParameter int
AS
BEGIN
-- Stored Procedure Guts
select 1
END
Good luck... ultimately, it just has to work for your team.
We are currently on the way to move from SSMT to SSDT. I see that we all facing the same problems and it is very strange that there is no good tutorial on the net (at least I haven't found it yet).
First of all about the variables. I think that you need to update to the newest version of SSDT (20015.02) + DacFx. We are using it and we do not have any problems with variables. It also has some new very good features as do not drop some objects on the target if they do not exist in the source.
However we came to solution to use synonyms for all cross database and linked server objects. For example we have table in the AnotherDatabase.dbo.NewTable. We create synonym [dbo].[syn_AnotherDatabase_dbo_NewTable] FOR [$(AnotherDatabase)].[dbo].[NewTable] and use it in the code instead of referencing the other databases. The same with linked servers: CREATE SYNONYM [syn_LinkedDatabase_dbo_NewTable] FOR [$(LinkedServer)].[$(LinkedDatabase)].[dbo].[NewTable].
Now about the development process. We set debug to our dev database in the project properties (later we are going to have separate databases for each developer). Then when you are modifying stored procedures/views/functions/etc... You open the script, change the CREATE to alter and you can work in the same way as you were doing in the SSMT. You can modify the body, execute it, execute queries in that window. However when you finish, you change it back from ALTER to CREATE and save the file.
The problem here is with the objects that does not support ALTER statement. In that case, you need to publish the code first. But in practice you are doing it so not so frequently so I believe that it is not so big deal.
SSDT is mature enough to use it to create your scripts and deploy your changes but you should move away from using the schema compare to doing deployments using sqlpackage.exe
The process looks something like:
-write code in vs/ssdt
-build project which results in a dacpac (either on your machine or ci server)
-deploy dacpac to db instance, using variables if you need to, to bring db's up to date. Use sqlpackage.exe to deploy or generate scripts which can be deployed manually
It should be pretty straight forward, but please ask if you are not sure on anything!
Ed
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)
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 :)
I have imported an existing SQL Server 2008 database to a Visual Studio 2008 database project, to version control database objects and perform database code migration. This works fine and I can build and deploy to dev, test, staging, live etc.
Now I want to add a new stored procedure (with a grant statement) to the existing database project and cannot see an ideal way to do this? I can either: -
Create the stored procedure in the development database, reverse engineer a script, and “import script” to my Visual Studio project.
Create the stored procedure directly in my Visual Studio project, but the grant statement raises an error there, so I will have to manually edit the xml in the “Database.sqlpermissions” script.
Create the stored procedure directly in my Visual Studio project. Then add the GRANT statement to the “Script.PostDeployment.sql” file. But now my permissions are spread across two files “Database.sqlpermissions” and “Script.PostDeployment.sql”.
What is the preferred way to add a new stored procedure with a grant statement to an existing Visual Studio 2008 database project?
My understanding is that the preferred location for permissions is the Database.sqlpermissions file. It can be a pain to work with IMHO because it forces you to switch from using the traditional syntax of GRANT EXECUTE ON OBJECT to GRANTEE to working with XML. IntelliSense makes it easier to get the syntax correct in the file, but it just isn't as easy to work with as writing the statement yourself, or even using the GUI in SSMS.
The syntax difference aside, the biggest reason I don't like the separation of concerns here is that it is difficult to see whether or not an object has an associated grant statement in the Database.sqlpermissions file. Maybe there is a way within Visual Studio and I haven't seen it, but it would be nice to be able to look at the properties of an object within the project and see a list of permissions for the object - similar to SSMS. (If anyone knows how to do this within VS now please let me know!)
I have this huge legacy database that I'm trying to get under source control. I looked around here on stackoverflow and decided to use the Visual Studio 2008 database project, then committing stuff on svn. I successfully imported the schema into the project, but I can't find any way to use the user-friendly table designers with this kind of project. Whenever I open a table, it opens the DDL definition. I need the designers, otherwise I won't get buy-in from the team. Any suggestions/workarounds?
I'd use Microsoft® Visual Studio Team System 2008 Database Edition GDR. Which scripts every object in it's own file so makes it easy to track in version control.
For developers that don't want to use the tool let them develop in Management Studio and then use the Schema Compare tool in Database Edition to automatically extract out the changes from their development database into the project files when they are ready to check-in.
You may be able to write some (cunning) Visual Studio macros to do the Schema Compare automatically with the minimum of clicking for developers.
I found sql server management studio (express free or the full product) easier to use than visual studio database projects. The one good thing i liked about vs was that you could select multiple objects (e.g. all tables) in the server explorer and generate a single script for them. These are not easy to maintain but are good for a quick back up of all objects.
Management studio has the table and query designers and also allows execution plans and client statistic to be displayed so you can optimize queries/sps if required.
I have only used it with visual source safe for source control which works fine from Management Studio point of view, but vss is not great! (buggy, crashes, corrupts etc.)
Try opening the Server Explorer (View > Server Explorer). You may need to add a connection and then you can to the database tables, right click them and choose "Show table data".
0nce you're there you get the Query Designer toolbar and you're able to use the table designers.