This is a great (beta) feature as it solves the problem of checking in SSRS changes together with the database schema changes into TFS in a single commit. Could this be looked at again please, now that SQL Connect has been retired.

Even if it isn't taken out of beta, could it be updated please (E.g. it is using RedGateDatabaseProperties.xml instead of RedGateDatabaseInfo.xml and saves objects in the wrong folders if there is .sqlproj file. (E.g. \dbo\Tables\)

Allow users to bind Red Gate Source Control in SSMS to a VS Data Project. This would provide an elegant State Based Solution complete with corresponding Visual Studio Project Template

Is this making out of beta? It has been years now.

Are there plans for this feature to make it out of beta?

@Anonymous: Are you using SQL Connect at the moment for connecting to a Visual Studio database project? Have you already tried using SQL Source Control instead? If so, what issues (if any) remain before you would be happy to use SQL Source Control as your primary tool for interacting with the VS database project?

To move the support out of beta status we would like feedback to confirm that it meets your needs in real-world situations -- and if it doesn't, what those limitations are so that we can look at addressing them.

Hopefully this can move from Beta soon since the Visual Studio RedGate Database Project takes FOREVER to load and doesn't allow me to just deploy a db locally.

@Peter: Improving support for branches in SQL Source Control is high up on our priority list and we'll be looking at it soon. For the moment, a workaround is to switch branches using your normal source control tool. Then in SQL Source Control, do a Get Latest to pick up differences in the new branch. After that, on the Commit Changes tab, right-click and Undo Changes. These steps should make the database match whatever is in the filesystem's new branch.

Paul, is there any guidance on how this should be set up or how it should work? How does SQL Source Control handle situations where we update our "dev" database, but then switch branches so those updates don't exist in the current branch? This sounds like it could be a great intermediate solution and I'm willing to give it a try, just not sure where to start.

I am looking at a solution for our SQL source control. I love RG Source Control, but since it only talks between live database to its own schema. I cannot use it to talk to my developer team with VS database projects. It's frustrated.

Hope there is a solution between.

We have a Beta build of SQL Compare that works with SSDT database projects.

http://www.red-gate.com/EAP/SQLCompareEAP/SQLCompareVS

After we get some feedback on this, we'll integrate the technology into SQL Source Control, which will mean the tools should play nicely with each other. As SQL Source Control uses the SQL Compare engine under the hood, it's very important for you all to let us know if it works for you, so we know what needs fixing before integrating with with SQL Source Control itself. Email any feedback directly to me at David.Atkinson@red-gate.com

Supporting SQLCompare with VS2K DB projects and .dbschema files would add value to our development processes. It would remove the need to deploy projects to live databases in order to compare source control with other installed dbs. The multi-faceted compare of Project<->.dbschema<->live db w/in VS2K still makes it essential for our uses. However, the strength of the command prompt interface for SQLCompare makes this a current win for building out automation.

Is continuous integration the only thing that you want from VS database projects? If so, we have more information about how to set up continuous integration and Red Gate tools at www.red-gate.com/ci .If this isn't quite what you are looking for I'd like to understand what your needs are (I've emailed you directly).

Just my two cents. We are starting a large project and I am a new hire tasked with the database development. One of my requirements is to provide database deployments in a continuous integartion environment. VS seems to do this well, (I'm still testing). But, and it's a big one,mI only have Vs professional which does not support DB compare etc. vs premium is another 4k per license vs 1500 for the redgate SQL tools. I am trying to hammer out a solution using both redgate and vs, but the two do not speak the same language I.e. e DB project in vs stores the DB meta data differently than redgate. If redgate's TFS integration matched vs DB project, then I could use both tools. So if redgate matched the souce control storage that vs uses, you would be offering users a chaper alternative to vs premium.

We've recently released SQL Connect, which is our source control story in Visual Studio. I'd urge everyone who has voted on this suggestion to give it a go and let us know how you get on. If you feel that you still need database project support, please let us know why! http://www.red-gate.com/products/sql-development/sql-connect

Yes this is a MUST!!

Thanks, Marty, for taking the time to expand on your comments. Being the only DB-centric developer/accidental DBA and having been bitten by the current VS DB Project required way of working, I was hoping there was a clear this-vs.-that kind of checklist, for want of a better word, that would help bridge the gaps in my experience and enable me to make a more educated decision over either wait for VS-next and embrace it, or ignore its features and attempt to use SQL Connect, a tool, again, one has no experience of. Thanks again.

I hope Red Gate can put together a feature/practice summary/white paper that clearly sets out the comparable features of RG Tools vs. VS-Next w/ SSDT so decision makers have what they need... Doubtless someone at RG must have given considerable thought to come up with SQL Connect and SSC in their current forms, knowing that VS-Next w/ SSDT was rapidly approaching...

@Stephen: correction should say " it is NOT a tool that is targeted for existing enterprise environments."

@Stephen: we have not looked into or researched the SSDT tools. We have fought through the current iteration of MS DB tools since their first version. We have worked with many individuals from MS, including some of the project managers directly, and the voice/concerns were never heard. We decided to not take our chances with the next version since the original version was released with so many issues and concerns. In all honesty, the current version works and does what it does quite well, but with our experience it is a tool that is targeted for existing enterprise environments. The tool works great if it is a very small database that is created within the tool from the inception. The simplicity and the approach that RG takes to mimic what SQL Server actually does is what is attractive to our teams. RG seems to understand enterprises much more than MS. MS has a tendency to focus on the volume distribution of their products vs value and function. Sorry I couldn't help more with SSDT but for now we are focusing on implementing a tool that doesn't hinder our productivity.

@Marty: tapping your 3+ years of knowledge, how would you compare the *upcoming VS release*, including all the SSDT functionality with the SQL Connect/SSC offerings from Red Gate. Which features IYE are incompatible and which are missing from the other? Which are roadblocks to enjoying SSDT? Which hinder RG Project/SSC usage?

I've no interest in the CURRENT version of VS vs. RG, only interested in finally being able to, at the very least, enjoy offline DB modifications with full impact analysis within VS-next.

Thanks in advance for sharing your understanding, provided you have time, naturally. Regular work = top priority.

We currently use VS DB Projects on a large dev team in an enterprise environment. We are working towards migrating to SSC and providing a substantial amount of feedback to RG in regards to SQL Connect. For those that are needing RG to work with a DB Proj setup I would like to ask why? If you are currently using the VS DB projects what functionality would you expect the RG tool to provide? The DB projects are already contain very advanced features. Actually the reason we are moving from them is the fact they are too advanced. The projects enforce rules within a solution that are not relative to the real world and the performance overhead is excessive in a large environment. e.g. No cross reference databases without the enormous overhead of partial projects;treating database projects and solutions like an object oriented project. Just curious as it is obvious that a lot of people feel this is needed and and we have been on DB Projects for 3+ years and have a very thorough understanding of that technology.