Me and my team are developing a SQL Server database. We want to work on different PCs, but with the same database. Is it possible that we can synchronise our work on each PC, or share our database while working somehow?
If possible how can Team Foundation server be used for that?
You can use SQL Server Database Tools (SSDT) to represent your database as a series of scripts. These scripts can then be added to source control. Git is by far the most popular source control system there is and Team Foundation Server and Visual Studio Team Services have great Git support.
Each developer will use Visual Studio (or VS Code) on their own machine to do their database work. When the developer wants to share their changes, they commit them to source control. Other developers can then update their local version of the code with the new changes. SSDT adds support for bringing your database and database project in sync.
Now that your code is in source control you can go a step further and add things like continuous integration builds and automated deployments with VSTS Build and Release Management. That way you can automatically test database changes and even run unit and integration tests before deploying to test and production environments.
The following Channel9 video gives an introduction to these tools: Database Continuous Integration and Deployment with Visual Studio SQL Server Data Tools in < 10 minutes
If you only care about schema changes (and not data changes), you can use visual studio's SQL Server projects, and a source control system, to help manage this. You can then use the Schema Compare tool to compare your project to the server, the server to your project, or server to server.
There are some tools from the likes of Redgate, etc, that allow this process to be automated. I've not used those, but they may be another option.
Related
Is there a way to generate change scripts from a Visual Studio and TFS project? I would like to either choose two versions of the database or enter a date range and get change scripts that I can pass off to a DBA to apply to the production database.
I do not have access to the production schema in order to do a schema compare.
My DBA wants SQL scripts and will not use snapshot method.
I am using Visual Studio 2013 and SQL Server 2008 and later.
Help!
I would suggest that your dba's attitude is blocking your ability to deliver high quality software on a regular cadence. Comparing with production is the correct and supported method to achive a change script. And remember the tools you are using are built and supported by the SQL Server team.
If you know when the current production version was shipped you can create a workspace and get that specific version of your code. If you compile it you should have a .dacpac for that version and you can use that in the compare.
Another option would be to ask the DBA to restore the last production version to another server so that you can 'test' the script. You can then generate your script from there.
Whatever you choose you need to raise this with management as a blocker for continuous delivery.
Related : Visual Studio 2013 (Professional Edition)
I am trying to create Data Migration Script to deploy the changes on Staging Server.
This works locally fine. But When I try to run the generated Script on Azure Database, I get TextPtr is not supported on Azure platform. I studied more about it & found that the newer editions of SQL Server (sply for Windows Azure (SQL 2014 may be)) has dropped some keywords/functionalities the list can be found here.
The Sql Database Project only provides the Schema Compare, but Data Compare is avilables in tools Section (where we can not set Target Project Type property).
I wonder how can I deploy/Migrate the changes made in one environment to another in such a Situation. Currently I had to overwrite the existing Database on Azure platform.
But this is not Identical also, for first time this could work but not for later, as there could be some changes made to the Staging or other environments.
I had a similar problem, when trying to migrate between a test and staging environment in Azure. As a quick fix, I got around the problem by just doing a "copy" of the dev database via the Azure dashboard.
Fairly long title, but hopefully self-explanatory!
I'm starting a new project in Visual Studio 2013 using Entity Framework 5.0 with code first migrations.
I've connected my project to TFS Online using git - I'm interested in trying TFS Online as it offers source control management for 5 free projects (similar to BitBucket) but with strong Visual Studio integration.
I've not used Database projects in Visual Studio 2013 and I've found little information for how this all fits together.
What I'm trying to acheive is to create a simple Visual Studio solution with 2 projects - one an MVC .NET project and the other a database project. My goal is that code first migrations will make the neccessary changes to the sql scripts in the database project (which are managed under git source control). My web.config points to a local .mdb file as my database which is what is updated when I run update-database in EF which is what I feel is the problem.
How can I point EF to use my database project for code migration, and subsequently how can I automatically build my development database into a local .mdb file when debugging my solution?
Entity Framework Code First is a way to manage your SQL Schema. The single source of the truth lives in your code base. Migrations adds a way to move from one version of the schema to another. The SQL schema is a by-product of the build process.
SQL Server Database projects are also a way to manage your SQL Schema. The single source of the truth lives in your SQL Server Database project. You can use schema compare to generate scripts that move from one version to another.
Given that these technologies overlap in their intent and functionality, it doesn't really make sense to use them together. When you're using entity Framework Code First, leverage Migrations when you can (and when the features are sufficient for your situation).
When you're unable to use Migrations, you could use SQL Server Database projects to manage the schema and keep them in source control.
Note:
You should consider installing the SQL Server Data Tools as a replacement for the SQL Server Database projects should you want to use these. The data tools are a more advanced version of these projects, even if they might require Visual Studio 2012 to run for now. I suspect a version for Visual Studio 2013 will be available when Visual Studio 2013 hits RTM
I am running SQL Server 2012 and VS 2010 with SSDT (SQL Server Data Tools) installed. My dev DB uses stored procs, functions, CLR objects, etc. It has a snapshot of prod data of about 500GB.
I created SQL Server Database Project and then imported the database. This created all tables, views, procs and functions files under schema names. Great stuff -- now I can do a version control just like in other VS projects, create deployments, etc. So far, so good.
But, I am confused as to what my development process should be for changing/adding procs/tables under SQL Server Database Project. It appears that any changes I make are applied to some LocalDb/Projects database and NOT to my dev database.
Am I suppose to author all my objects in that LocalDb, then Build and deploy to my dev database via Publish? I am worried about my existing tables in the dev DB since if the publish process drops and recreates tables, I will loose my prod data snapshot.
What is the right development process to follow in SQL Server Database Project?
Think of the source database (in your case, your database project) as being the "to be" state after deployment. When a deployment is initiated, the executable (SqlPackage.exe) compares the source with the target and generates a difference/delta script to make the target look like the source. This is why we no longer have to specify CREATE or ALTER; the tool figures it out. To answer your question about ongoing development, you can develop either way. You can develop in the project files and publish them to a common Dev database (say, if you're on a team), or you can develop in the database with tools like SQL Server Management Studio (SSMS) and synchronize with the project files with a schema compare (I use the latter technique because I like SSMS).
For deployment, you'll have to have SSDT installed on the machine from which you execute the deployment (SSDT ships with SQL Server 2012 and later; I don't know about SQL Server 2008). You can create scripts to simplify deployment. You'll essentially call SqlPackage.exe (it lives in x:\Program Files (x86)\Microsoft SQL Server\nnn\DAC\bin) with an action and a source. I use Publish Profiles as well to take care of most command properties. So an example deployment might look like this:
SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml
For more information:
SQL Server Data Tools Documentation
http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx
SqlPackage.exe Documentation
http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx
Make changes inside the VS DB project.
Deploy changes to localDB to test
Publish the database to your production server. I prefer to use Schema Compare to do this manually, but you can also publish the project via the right click --> publish menu (which will also create a publishing profile), or using command line arguments. The publish process won't drop and create tables (unless you tell it to drop & recreate the entire db).
Alternatively, in the project settings you can change the connection string to point to your production server (as pointed out in the comment). However, I recommend against this, as it will then attempt to publish to the production server every time you run a local build (F5).
I have developed a windows form application. I have also created a database on sql server and added data to this database.
Now i want to install this application at clients place. I want to know the ways to move my created database on client's location. How can i do this during application installation? If i have to include database scripts in installation file and run it.how can i do it? If its a long process please specify links which helps me in accomplishing this task.
Thankyou very much.
Look at the GDR R2 database project (part of Visual Studio).
You can use this to reverese engineer your existing database into scripts within a Database project, and place under source code control. You can synchronise existing and deploy fresh databases from this project.
Visual Studio 2010 SQL Server Database Projects
An Overview of Database Build and Deployment
Visual Studio Database Guide
You can also use commercial tools such as those sold by RedGate.