Over the last few months, we at Red Gate have been working towards adding SQL Server Database Project compatibility to SQL Source Control, our tool to add database source control in SQL Server Management Studio. I’m pleased to announce a beta release of SQL Source Control is now available for download from http://www.red-gate.com/SQLSourceControlBeta/DataToolsSupport.
This beta allows SQL Source Control users to link to the SSDT project folder in a repository (those containing a .sqlproj file). Therefore, mixed SSMS and VS teams can now work on the same database code using SSDT projects.
It’s important to stress that this is a beta-quality release of SQL Source Control, and as such it is only intended for experimental use. In particular, we are aware of some limitations regarding database-level extended properties, permissions and CLR assemblies. If you encounter these limitations or any other problems with this new SSDT compatibility, please let us know by using the Feedback link in SQL Source Control, so that we can best prioritize bug fixes and provide a robust release in the coming weeks.
The current beta is free and will remain functioning until 8th May 2013. We may update the beta as we fix reported issues.
Software Developer – Red Gate
UPDATE: 10th May, 2013
The functionality from the expired beta release mentioned above is now part of the main SQL Source Control release. Existing users can use 'Check for Updates' from within the tool to update to the latest version. Anybody wishing to evaluate the tool can download a 28 day trial from http://www.red-gate.com/products/sql-development/sql-source-control/
- Edited by james.allison Friday, May 10, 2013 1:56 PM
When I tried to setup a link from my dev database to TFS database folder, which contains the database.sqlproj, and hit error "The path must be an empty folder".
Also, I noticed the trial version is 126.96.36.199, and the recent released one is 188.8.131.52. Which means the released one has already supported SSDT?
Hi there Fei,
There are actually two branches of SQL Source Control, one containing SSDT Support and the other not. The version that you are downloading here does support SSDT however when you are prompted to "update" within SQLSC it's actually trying to update you to another branch (one that does not support SSDT).
If you require SSDT Support do not update unless you have been notified by Red Gate that an update has become available for the SSDT branch. (Of course you will only get notified if you opted in for notification)
When the update becomes available I will try to remember to post a little note in here for you.
@Fei Du: Brendan is right -- we released an updated SQL Source Control to fix some bugs, but that version doesn't yet contain the SSDT project support. As it was a higher version number than the beta, you were offered the update. Sorry about the confusion: our next beta will have a much higher version (3.1.90) and so shouldn't suffer from this problem again.
Could you try uninstalling 3.1.2 and then re-installing 184.108.40.206? We think that linking your dev database to a TFS database folder shouldn't give you that error message, but if it still does then please let us know.
Thanks for trying it out and for giving us feedback!
Project Manager, Red Gate
There is now a new Beta of SQL Source Control (SSDT Support). This build includes a fix for committing objects to Git and Mercurial repositories.
I would like to repeat James Allison's cautionary advice in the original post above:
"It’s important to stress that this is a beta-quality release of SQL Source Control, and as such it is only intended for experimental use. In particular, we are aware of some limitations regarding database-level extended properties, permissions and CLR assemblies. If you encounter these limitations or any other problems with this new SSDT compatibility, please let us know by using the Feedback link in SQL Source Control, so that we can best prioritize bug fixes and provide a robust release in the coming weeks."
Test Engineer, Red Gate
We have had reports that some SSDT project files that were themselves upgraded from old .dbproj files were not working properly with SQL Source Control.
We have made a third beta release (version 220.127.116.11) that addresses this problem. This is available from the same link in James Allison's post above. Please give it a try if you'd like to work on your SSDT projects inside SQL Server Management Studio.
Feedback always welcome on this forum!
Project Manager, Red Gate
Thank you for addressing an issue that was causing us substantial problems. We are currently testing the beta release and there seem to be several issues that are stopping us from being able to use this functionality. I'm sending errors as I get them, but would like to make sure my approach and understanding of the solution is correct. Here are the steps we are following to use source control with SSDT:
1) In Visual Studio 2012, we create a database project and add all schema/objects.
2) In SSMS, we link the database to the TFS repository location from step 1.
3) We run a compare to add objects and resolve conflicts.
The first 2 steps run fine, but the last one chokes every time and I have to delete the local code base from RedGate source control to attempt the linking again. Is my understanding correct that this crossover functionality in RedGate SQL Source Control is intended to allow developers to leverage the tools/assets of Source Control in SSMS in addition to the tools/build features of SSDT & TFS in Visual Studio?
Thanks for taking the time to tryout this new functionality. Your understanding is correct, this is the intended use - being able to commit changes to a version controlled Data Tools project from both Visual Studio and SQL Source Control in SSMS.
We've received your bug reports, many thanks for sending these on. I'll be in touch to get a little more information about the issues you're experiencing.
Software Developer - Red Gate
James I have had some exchanges with your Paul Stevenson and John Allison as well As adding to feedback and surveys. However it has been some weeks without Amy response. My main issues with the current Beta is that it has issues with resolving Security permissions and roles etc from the SSDT project and saves schema objects as dbo.objectname.sql whereas SSDT saves the object as ObjectName.sql In other words Sql Source Control can read SSDT projects only to a point and is unreliable in the other direction. What about SSDT reading a SQL Source Control repository back to a VS project to complete the circle? Does "Connect" have a space here? Regards