April 22, 2015 at 4:46 am
I use Management Studio primarily, but still use VS for Data/Schema comparison and creating deployment scripts.
May 27, 2015 at 10:21 am
I have a huge list of stored procs in my database and I can't find a way to filter them in SSDT (or any other object type for that matter), so I'm sticking with SSMS.
June 4, 2019 at 4:30 pm
June 17, 2019 at 7:16 am
I'm gonna go all "Four Yorkshire-men" on this and comment that back in my day, we'd been glad for ISQL/W. We would use SAF in character mode and be happy! None of this "window" rubbish! 🙂
June 17, 2019 at 7:18 am
Evidently, I wrote much the same thing 4 years ago. 😛
June 17, 2019 at 7:52 am
I have used SSDT but I live in SSMS.
June 17, 2019 at 8:34 am
I use SSMS more. I would happily use SSDT more if it wasn't so flaky and crash prone!
June 17, 2019 at 10:33 am
I use both. SSMS for DBA tasks, SSDT for development tasks.
The reverse engineer/import db functionality in SSDT has been a huge time saver when starting work with neglected legacy db's; Being able to instantly see potential problems in the code (3 and 4 part references, broken queries, etc.) simplifies understanding and planning of architecture.
For running ad hoc queries and peformance tuning, SSMS is still king. For everything else, SSDT wins hands down especially with multiple deployment environments and multiple developers when integration with source control and continuous deployment/integration are necessities.
June 17, 2019 at 10:35 am
It depends on the project, for new greenfield databases where we can can stop the rot before it sets in then SSDT - older projects that have "issues" i'd probably stick with ssms./azure devops and a migrations based deployment approach.
June 17, 2019 at 11:23 am
I use both, but prefer SSMS. It is more flexible.
June 17, 2019 at 11:29 am
For us, SSMS and SSDT are different tools that serve different purposes. We use both, all day, every day.
We use SSMS for system administration and general server management. SSMS also excels in everyday querying and data investigations/analysis. In fact, we do almost all our development and (manual) unit testing using SSMS.
BUT, when it comes time to deploy code, it makes much more sense to use a tool like SSDT. Many have mentioned that it integrates well into source control and I agree it does so very well, but there are other capabilities we leverage within the tool (pre/post deployment scripts for example) that allow us to essentially deploy any version of our code to any version of our database.... at the click of an icon. That is a pretty big deal.
For years I had manually arranged scripts using SSMS (and its predecessors) carefully orchestrating the sequence of steps involved in a change/new version of our app, and this required a considerable amount of effort. SSDT takes care of that for us.
Our dev team couldn't live without either tool at this point. I do wish the easy of querying and server admin stuff was available within VS/SSDT so we'd only have to use one app. One can dream.....
June 17, 2019 at 12:21 pm
Hi, use both but prefer SSDT as a Project in Visual Studio together with my SSAS, SSIS and SSRS projects.
One Solution to change them all!
June 17, 2019 at 12:51 pm
I use Visual Studio or SSDT for SSIS package development and schema / data comparison. However, I find the UI too cluttered and AppDev centric for it to replace SSMS as my primary tool for SQL Server. I'm also looking at Azure Data Studio.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 17, 2019 at 12:58 pm
I use SSMS for all my SQL development; however, now that the Teams integration and debug options have been removed in version 18.x forward, I may need to start thinking about moving to VS.
June 17, 2019 at 1:14 pm
Even though I'm nearly always in Visual Studio, I still use SSMS for any serious database work. It's so much more complete, I can trace queries, check the query store and then change/test the offending SQL.
Viewing 15 posts - 76 through 90 (of 97 total)
You must be logged in to reply to this topic. Login to reply