SSMS or SSDT

  • Used both, prefer SSMS.

  • I use both, but I've probably been using SSDT since I'm doing more with SSRS.

    Christopher Reed, MCT, MCSD, MCPD, MSpec, MTA, MCTS
    "The oxen are slow, but the earth is patient."

  • Comments posted to this topic are about the item SSMS or SSDT

  • Historically I have used both but SSMS substantially more (even in the time frame when they both have existed).

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I'm primarily a C# developer (with a heavy DB focus), and I spend most of my time in Visual Studio, but I find SSMS more comfortable for DB work (with an add on or two).

  • I use both.

    In a shared environment (multiple devs to one DB) I find SSMS works better than SSDT.

    But if you can get to the point where you do your dev on a local instance, SSDT is my preferred environment. The ability to build and publish is very cool and integration with source control works better.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Management Studio open all day for database management and sql querying then either Visual Studio 2008 for SSIS/AS/RS development as we're on SQL 2008 for those or Visual Studio 2010 for ASP.NET development.

  • My emphasis:

    Phil Parkin (3/27/2015)


    ...SSDT is my preferred environment. The ability to build and publish is very cool and integration with source control works better.

    Good point.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • others bemoan the demise of isql/w

    Yep. I was one of those people. This thread brought back some memories.

    I do all my SQL in SSMS. SS%S happens in Visual Studio.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001

  • I use SSMS almost exclusively.

    Used to use Enterprise Manager and ISQL but don't really miss the latter much!


    Cheers,

    Sue

  • My work involves both maintenance/enhancement of existing databases and the creation of wholly new databases. For the former, I'd most likely use SSMS since it is easier to experiment on views and procedures there. For a new database, my preference is for SSDT.

    SSDT offers easier methods for linking to source control (Ankh to Subversion), the more so since not all the developers here have the Red Gate toolset (including SQL Source Control). I also find the table scripts made in SSDT are more appealing - as well as the table definition, all foreign keys, constraints, triggers and permissions are in the one script. The use of variables in an SSDT project means that I can deal with environment-specific users in a generic way. I can also have several related databases in a single solution (eg Staging and Warehouse).

    Sebastian

  • I work with creation of new SQL code as well as maintenance, and due to the different servers and versions I use SSMS almost exclusively.

    but also use Enterprise Manager as this is still on some of the servers we have to work with.

    Health care is not one of the areas where a lot of money is available for upgrades.

  • ISQL/W... Pftt! New-fangled stuff.

    I remember when I did most of the work in SAF on SQL Server 1.1. Those were the days...


    Just because you're right doesn't mean everybody else is wrong.

  • Never tried SSDT, so SSMS exclusively. For one thing, it doesn't require the additional Visual Studio install if essentially all your work is directly in the database.

  • I mostly use SSMS. I do like SSDT when creating a new database, and also try to use it to keep the deployed version of the DB linked to version control.

Viewing 15 posts - 1 through 15 (of 97 total)

You must be logged in to reply to this topic. Login to reply