We currently have our database objects in TFS2012 and happily use redgate sql source control to check in & getlatest. So far this works great.
I now want to use SSDT in order to create a dacpac that defines the latest schema.
What I'm missing is how to link the SQL Server database project so that a check-in via redgate source control would ripple through to the database project (upon a getlatest) and therefore schema changes would be shown in the dacpac upon a recompile?
thanks
As it's 3+ months after I posted the question, and https://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answer-your-own-questions/ I guess I should state what the outcome was...
We had a number of unresolved (at the time at least) issues automating SQL Compare, which was the reason for looking into SSDT in the first place. The more we looked at SSDT the more we became impressed with it (still has some issues, but doesn't everything?) to the extent that we have now dropped our use of redgate, therefore the need for SSDT to play nicely with redgate is no longer required.
This is not to say we're not a fan of Redgates products or that the answer is to drop redgates products - just that they didn't meet our requirements when our requirements changed (we started to automate everything).
I'll still be sending Redgate a Christmas card, honest :)
Here's a document describing how to use SQL Source Control and SQL Compare in conjunction with SSDT database projects. It's beta functionality, and we're aware of a few issues, but please report them to us (support#red-gate.com) so we can prioritize our backlog.
Related
I have an ERP system which I maintain with a team of people. However lately we seem to be loosing track of who's changing what and we need a solution to be able to control these changes. We are looking into the enterprise version of GIT as all our software development and web development would work perfectly with it. Not to mention I have some experience with GIT already.
The problem is we need the version control to extend to our SQL Server which we use SQL Server Management Studio to maintain. We have thousands of tables in 6 main databases which have a lot of stored procedures which are being changed.
It's not so much we want to control the source as in, permissions and refuse changes by people. It's more, we need a way of tracking changes and attaching explanations to help our future selves.
Does anyone know any solid solutions which would fit our purpose?
Assume the cost isn't a main factor.
I was using RedGate tool. It can integrate with Git.
RedGate SQL Source Control
I have been asking myself this question once. So I've found following solution which I can suggest you to use.
It is a SQL Server Data Tools that solves the problem.
The tools include SQL server database project for visual studio. This project will store your database structure. You can just add it to you solution. Then run a schema comparison with your database to take a snapshot of your current database state. You can choose what objects to compare. Since this moment your have all your changes being tracked by your VCS. Every change is documented now.
You can make changes in DB project and when you are done just run schema comparison, get the update script and apply those changes to your SQL server database. It is really not that hard to work with your schema from DB project as it provides intellisense, syntax validation. Also it is possible to write and execute SQL queries against you database.
We are planning on using Red Gate SQL Source Control, but have not yet decided which source control system to use yet: you can use Subversion (SVN) or Team Foundation Server (TFS).
Which one should we choose and how does that affect the way Red Gate SQL Source Control?
Here are some factors that might affect our choice:
We use SQL Server 2008 R2
We do not currently use SVN or TFS
We will not be using either SVN or TFS to source control our non-database code
We get TFS with our MSDN license, so cost is not a factor
We work both in the same office and remotely
Any help or advice would be appreciated.
EDIT: For non-database code we use VSS, which we are going to replace with Mercurial (with Kiln) later this week.
EDIT: Since posting this question, I have found out that Red Gate SQL Source Control will work with any source control system that has a suitable command line. So, we could get it to work with our implementation of Mercurial/Kiln and would definitely consider that. Any advice on that would be very helpful.
I have only worked with SVN with Redgate Sql Source Control, though I have worked with TFS outside of the context of database source control.
My take is this: barring deep integration with the methodology templates in TFS, there's no advantage to using TFS in this situation. The integration with SSMS is very common-sense and intuitive for SVN, so it's worked very well for my team.
I personally found TFS pretty heavy, administration-wise, and have found SVN server very light and easy to work with. If you've got someone who already has TFS Administration experience, that might be an argument for TFS, but barring that, I'd recommend SVN.
I keep coming back to one factor: I could have SVN up and running with this system inside of an hour, and God knows how long with TFS.
As per your update - if it's possible, I strongly recommend getting it integrated with your existing repository, but if it's a choice between waiting for the perfect integration and getting your db's under version control today, there's no choice in my mind.
SQL Source Control has an Early Access Release that works with Mercurial. It would be great if you could try it out. You can find out more information at http://www.red-gate.com/messageboard/viewtopic.php?t=12786. Like Chris said, it's probably best to have one source control system for both your application and db code if possible.
We are planning to put out SQL Objects (Tables, StoredProcedures, UDF's and Views) under our existing TFS 2010 versio control.
Is is possible that any check-in's made to the objects under TFS version control gets automatically sync'd to our Development server. The technical team here are not so interested in having to make changes at 2 different places (Development Server + Check-in at TFS server). Its an overhead process change for them.
Late answer, but I hope it can be useful:
Recently, I've tried to find the solution for a similar problem, and I've bumped into a sql source control add-in for SSMS that works with the TFS, and I found some answers by reading this article:
SQL source control reduce database development time
I think it can be useful for you too (in case you couldn't solve your problem)
Hope I helped.
The best solution by far to do this is to use Red-Gate Source-Control. You will not find a better and easier product to do this, and all the other benefits you get from using it is huge. For example, it integrates 100% into SQL Management Studio.
You should use Visual Studio Database Projects. You'll get the best of both worlds! Source control and automated builds and deployment.
I found the solution to my unique scenario. I used the Sql server management studio project by using the TFS plugin for SSMS. Team can now easily make changes in the Development environment using SSMS and make check-ins at the same place. Nice and easy way to do things without additional overheads. However, this only solves the purpose of version control. I am still researching on how can we do schema compare and automated deployments using SSMS projects.
I'd like to have all DB DDL code under CVS.
We are using Subversion for our .NET code but all database code remains still unversioned.
All we know is how important DB logic can be. I've googled but I've found only few (expensive tools). I believe there exists other (cheaper) solution(s).
What approach do you advise to follow? What tools are most appropriate?
SQL Server 2005, VS 2008 TS, TSVN
UPDATE
Our coding scenario is that developers cannot access to PROD DB directly. It is changed only by scripts (so this is not a problem)
I'm mostly interested in the DEV environment where all of developers have full access.
So it happens that a developer overwrite USP previously changed by another.
I'd like to have the possibility to restore lost version / compare USPs revisions etc.
UPDATE-2
To create deployment script we are using Red-Gate SQL Compare.
Works perfectly - so deployment scripts are not a case.
If you haven't already read it, Martin Fowler's article Evolutionary Database Design is a great place to start.
The article is hard to summarize, but it describes how his team dealt with database versioning in a rapidly changing development process. They created their own tools to facilitate things: scripts to bring users up to the current master, to copy any version of the schema so users could debug one another's working copies, etc..
For a solid low-tech solution, I've found it helpful to keep two kinds of DDL scripts in source control:
A master version that can create the database objects from scratch.
'Version upgrade' scripts for each development iteration.
They're redundant to a degree, but extremely useful (particularly when it comes to deployment).
If you haven't already looked at the Visual Studio Database Edition GDR (a.k.a. "Data Dude"), you should definitely download it and try it out:
http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en
Among other things, the GDR will facilitate team development by making it easy for each developer to maintain their own local copy of a database, version scripts, create deployment scripts to move a database schema to a new version, and even support database rollback.
It's free if you are using team system developer edition. Check it out.
If you are using Visual Studio Team Suite or Visual Studio Developer Edition, you are entitled to a copy of Visual Studio Database Professional. This is designed to do exactly what you describe, and much more. We use it to manage our database schema (code).
Randy
We use Subversion for all our database code as well. Since nothing is allowed to go to Prod unless it is in a script, there seems to be no porblem with getting people to put all the scripts into subversion. We tend to write alter table scripts to change tables with existing data and then recreate the whole table structure in case we need to create a new database from scratch (we often have the same database structure on multiple servers as some of our clients are very large and do not want their data accidentally available to the competition and so pay for separate servers and therefore may need to create the whole database again with no data.) For objects that don't directly store data we drop the orginal object and recreate it with a create statement. Each project has it's own home inthe repository and each database does too, so the script may be in more than one place to facilitate deployment.
But the real key is that no one can load to Prod without a script. We don't give our devs direct rights to prod, so they have no problem doing things in scripts as opposed to using SSMS.
I wrote SMOscript which generates a CREATE script for each object in a database.
Use this tool to generate into a directory covered by CVS, and update your repository.
Finally I found this tool and approach extremely useful and very easy to introduce
(at least at the beginning - where no versioning solution on the place):
http://www.codeproject.com/KB/database/SQLScripter.aspx
You can run it out of the box.
For final solution I'd incline to GDR.
This also sounds interesting:
Freeware:
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133
Commercial:
http://www.nobhillsoft.com/Randolph.aspx
You should use Management Studio (SSMS) and place the .sql under source control, possibly separate schema objects under folders.
Hope this helps
See if Wizardby fits your needs.
Interested if anyone has used VSTS Database Edition extensively and, if so, which features did you find the most useful over the standard Visual Studio database projects?
What are the most compelling features as opposed to alternative schema management options or tools like RedGate's SqlCompare etc?
Edit: Microsoft just released the RTM version of Database Edition (GDR) which adds support for SQL Server 2008 - link is here. I've previously blogged (briefly) about it here.
Has anyone had a chance to do any real work with the GDR? It looks like there are some real enhancements including refactoring support. I'd be really interested to hear if people are using it with SQL Server 2008...
Download From: [http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en]
We use the database edition functionality of Team Suite on Stack Overflow. As Vaibhav said, mostly it is useful because it gives you a one-click way to reverse engineer a database into source control, and keep it up to date.
Note that it also has decent Data and Schema compare tools as well. You can compare projects to physical databases and vice-versa. This makes it pretty easy to keep your database up to date, no matter where you make changes -- in the filesystem database project, or in the physical database itself.
If you compare it to tool like RedGates, that are specifically taylored for SQL Server, the benefits are that if you have the proper MSDN subscription you do not have to spend more money for other tools (but keep in mind that RedGate tools are much more mature) and it covers some points (like regression tests and unit tests at the DB level) that other tools do not cover and it make so in a integrate manner with other testing tool of VSTS, so that you can record results in Team System.
Compared to a tool like Embarcadero ErStudio (my solution of choice) it misses the cross database features, and this is a big problem, at least for me.
If you are a "all Microsoft" shop with the proper MSDN subscription it could be worth spending time on it.
We are currently using the GDR 2008 projects for managing our entire database development and deployment on a greenfield system. We use a TFS build script to call out to the MSBuild task for deploying the databases along with executing the data generation plans for pre populating the testing environment with data.
The key with the data generation plans was finding the build task to use which is :
TaskName="DataGeneratorTask"
AssemblyName="Microsoft.Data.Schema.Tasks, Version=9.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
All of this gdr project work has been unbelievably helpful and I think it is well worth the learning curve to get to know these project types. The value they provide is astronomical in productivity and visibility.
It allows us all to view the entire system in a single visual studio solution along with allowing us to start with a clean slate of our system at any point in time with either a click of the deploy command or a custom build configuration.
This blog
will help with getting the TFSBuild script to run if you're interested.
The VSDB test integration is so painful to configure that we abandoned it, and that's the only thing it's got that Red-Gate doesn't.
Red-Gate's tool is miles more useful. It does live DB and scripts in folders, but also has "snapshots." The aspect of Red-Gate SQL Compare that gives it the win is its Snapshot ability and the fact that your license allows you to deploy their assemblies and use them to perform database maintenance at customer run-time.
It has made upgrades in the COTS application that I develop a breeze. A Snapshot is a binary schema representation. You can package them as resources in an assembly, then use the snapshot in a customer run-time schema compare to bring an existing database up to the current rev.
Probably the best advantages are around being able to version control individual DB schema objects (which you could do with the older "Database Projects"), but have the power to "build"/deploy the project and convert those individual scripts into a complete database.
The ability to import scripts and have the Wizard covert individual schema items into separate files is very handy if you've inherited a DB schema.
Given that recently the licensing model changed, it makes it even more enticing because it's included with the Developer edition SKU. It also provised support for "Database Unit Tests" which might be useful.
From the 2008 GDR, I understand that they now support SQL Server 2008.
You can do database versioning for one. That is useful.
The other thing that is really useful is the ability to define type of seed data for testing. Through this Visual Studio will populate the database with random data and this is great for testing purposes.
There are other benefits as well of course.
It is always useful to put everything under the same source control, so your data-dude can be shelving, checking in, compare with history, and even resolve workitems and bugs using the same tools that other team members are using.
Also to be able to have one versionning mechanism across the whole application, in other words, it doesn't make sense to say that my source control has all the versions of my project while your database can't fit with any of these old versions, unless you take a backup or a snapshot of the database with each build.