Evolving Our Tools

This week the next preview version of SSMS v18 was released. This is the sixth preview release, and I’m guessing that this will be one of the last. Six seems like a lot of releases, and I’d like to think that this is getting close to being ready to use by most people, but I’m not sure. I certainly have some some annoying and problematic bugs, so I can’t be sure there won’t be a seventh, eighth, or ninth preview, but it does seem to be fewer issues are being reported.

With the release of SQL Server 2016, SSMS was decoupled from the database engine, and we saw some SSMS v16 releases. I didn’t use many of those before moving to SSMS v17, which came slightly after SQL Server 2017. I’m glad we’ll start to get the versions separate from the engine as this is confusing to many people. However, I do expect that plenty of people will call this SSMS 2019 or think there’s a SQL Server 2018, etc. If we could get more people to leave the older SSMS versions that came with 2008 R2, 2012, 2014, then I’ll take a little confusion in how we talk about SSMS.

However, we don’t need to stick with SSMS these days. If you’ve been heads down and just focused on keeping your existing systems running, you might not realize that not only do we have different SSMS choices, but we also have other tools. I’m not talking about SQLCMD, bcp, and Visual Studio, but we have other ways of working with SQL Server. Visual Studio Code has an mssql extension if you write code in that IDE, which might be something you full stack developers need.

For the SQL Server people, we have a fork of VS Code in Azure Data Studio. This is a lighterweight IDE built for SQL Server work. We also have the mssql-cli tool, giving us way more control over command line work than we have with SQLCMD. I haven’t worked with it much, but it’s on my list for January to play with a bit. I don’t know how well either of these will catch on, but let me know your thoughts. Are you doing more work with either of these tools?

There are certainly plenty of other choices as well. My company (Redgate) and others make plugins for SSMS that improve how you work with SQL Server. There are even other IDEs, such as DataGrip, that you can use and abandon the Microsoft tools altogether. I’m not sure I would look to leave SSMS entirely, but perhaps I should give some of these a try at some point.

Tools matter to many professionals. Mechanics treasure their sets of wrenches, chefs love their knives, and we ought to have tools that we know, use, and are comfortable with. This includes both the actual software and the various scripts, code, and helper applications that allow us to work efficiently. If you don’t love your tools, or have a collection, maybe now is the time to start the new year building some skills with the one you use, or try a new one. Wayne Sheffield has a nice series on SSMS and I’m hoping to get some other pieces written for other tools. If you want to tackle one for SQLServerCentral, let me know.

If you’re looking for a new tool to try for SQL Server work, might I suggest some PoSh and dbatools. It’s an amazing combination for lots of tasks.

Steve Jones

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , , , , . Bookmark the permalink.

1 Response to Evolving Our Tools

  1. Rod Falanga says:

    I haven’t seen SSMS v18 yet. We’re only getting up to SQL 2016, so I don’t think I’m in any disadvantage using SSMS v17. I also use Azure Data Studio. In fact, Azure Data Studio is becoming more my go-to tool, for T-SQL development. I really appreciate your listing other tools, most of which I didn’t know about. Thanks!


Comments are closed.