Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

According to the official SQL Server Documentation, the use of "Solutions, Projects, and Items" is deprecated. A conspicuous (though somewhat cryptic) warning banner at the top of the MSDN page states:

"This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature."

Unfortunately, no suggestions for alternative storage/container strategies are offered. So what is the recommended way for storing and packaging the various scripts, queries, and files that make up your database application? I would also be very interested to know if any of you are acually using the Solutions or Projects framework in your current work, and what you use them for.

[Note: I realize that I could use VS2010 for this functionality, but I am interested in SSMS-based approaches (for the reasons expressed in the answer to this question).]

share|improve this question
    
Red Gate: Tools, Sample Process –  Nick Chammas Jun 14 '12 at 16:59

2 Answers 2

Here at Red Gate we've just released a build of SQL Source Control that works alongside SSDT, providing a way to manage and source control database changes from SQL Server Management Studio, working against the database project repository.

More details and a download link can be found on the SSDT forums themselves:

http://social.msdn.microsoft.com/Forums/en-GB/ssdt/thread/0c763f98-c55a-44a7-9100-80a6d9223d04

This is a free-to-use Beta build. We're currently looking for community feedback before we merge this feature into the full release.

share|improve this answer

Reading between the lines, I guess the expectation/plan was for the SQL Server Data Tools (SSDT) project type to be extended to SSMS for the release of SQL 2012. Evidently that didn't happen, so we're stuck with the (frankly dreadful) SSMS interpretation of a project.

If you want something to manage your database source, you should be diving deep into SSDT. I'm currently using it for one greenfield project and also moving a large brownfield database to it. Minor niggles and pain points but no show stoppers and we're getting payback on the time invested already.

Jamie Thomson, who blogged extensively on VS2010 Database Projects (the predecessor), has started to publish articles on SSDT and appears to be as big a fan as I am. Bob Beauchemin is another early adopter worth following.

If you want to organise a collection of random scripts (rather than a full database build) you can but support isn't quite "first-class". To do so, create a standard SSDT project type and change your scripts to compilation type "None" in the file properties.

share|improve this answer
    
SSDT works in the Visual Studio environment. While I'm sure it is powerful and useful, I am looking for a SSMS-based approach to this issue, as I expained in my Note above. –  kmote Jun 14 '12 at 16:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.