Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

SQL Development tools strategy Expand / Collapse
Author
Message
Posted Wednesday, September 3, 2008 11:06 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, October 22, 2014 9:21 AM
Points: 847, Visits: 476
Generally speaking, I have always used SSMS (or the equivalent in some other version) for development. The integration of SourceSafe was a real boon to me, and most of our production databases have become SSMS solutions.

Recently we inherited an application, with database, where the database development was done in Studio Pro, resulting in .dbp projects. As far as I can tell, they are incompatible with SSMS solutions. Am I missing something in that?

For the bigger question, where SHOULD the development take place?


------------
Buy the ticket, take the ride. -- Hunter S. Thompson
Post #563221
Posted Wednesday, September 3, 2008 11:53 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 6:53 AM
Points: 13,890, Visits: 28,285
Those files are not compatible with Management Studio.

As to where... it really depends on your shop and the processes there. For example, we use Visual Studio Team System Database Edition for our database design, development and deployments. It integrates very well with source control, validates database scripts in a sandbox as you develop them, provides mechanisms for deployment to multiple servers... Except for some shortcomings in incremental deployment automation, it does just about everything we need. Unfortunately, it's pretty expensive, so some shops might not be able to take advantage of it.

I know others that are using a combination of Management Studio and Red Gate SQL Compare. I used to do it that way myself. It really depends on your processes, how much money you're spending on tools, how much automation you need, etc., to decide on where precisely to do development. I wouldn't say any answer is wrong outright (unless it doesn't include some kind of integration with source control because that's just foolish).


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #563253
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse