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).]

2 Answers
2

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.

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: