Voice of the DBA

Author: way0utwest

  • The Ideal IDE

    When I started working with SQL Server, I spent a lot of time in Query Analyzer and isql.exe. Those were my two main tools, using those to query a database instance in a lightweight manner. At some point Microsoft released Enterprise Manager, which was more useful for some tasks, but overall, I preferred Query Analyzer. Eventually that died away, and we got stuck with Management Studio, which most of us now use. Along the way, I also used DBArtisan, RapidSQL, and a few other IDEs for writing code against a SQL Server.

    These days we have a few choices for doing development and administration on the Microsoft data platform. There is still SSMS, but Visual Studio has gotten quite a few upgrades and extensions to allow work with everything from a local SQL Server to a cloud database to data lakes and more. Microsoft built a lightweight IDE in Visual Studio Code, and released a SQL Server extension for that tool. In the last year, we also saw a preview release of SQL Operations Studio (SOS) from Microsoft, and perhaps this is the direction that Microsoft is moving in the future. There are also other IDEs, such as DataGrip, that some people are using.

    I’m still stuck in the the SSMS mode. Even when I use Visual Studio for SQL Server work, with something like SQL Change Automation, I often switch back to SSMS for lots of my work. I’ve done some work in SOS, but I don’t love the experience overall. Since I have SSMS running most of the time, the speed of SOS isn’t helpful. If I were shutting down and restarting SSMS often, I might feel differently.

    Today I’m curious. I’m sure you all have preferences, but if you could choose only one IDE, what would it be? Let’s imagine that we’re not looking at the current state of the tools, but for whatever functionality you need, whether that’s database development tools, AG management tools, scheduling tools, etc., all of the functionality would be added to VS, VSCode, SSMS, SOS, DataGrip, etc. In that case, what do you prefer?

    I think I’d lean towards keeping SSMS, though I wish it were more open and extensible. Since that’s not likely to happen, I think SOS might be my next choice as an IDE if it has lots of extensions, and I have the ability to enable or disable them for the functionality I need.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Refreshed and Back from Vacation

    It was a nice break to get away from work for a couple weeks. My family and I traveled 2,000+ miles to Glacier National Park. We camped out each night, and managed to get to both Yellowstone (briefly) and Glacier. Obligatory pic below.

    FB_IMG_1533396327208

    For the most part, I was unwired. There were plenty of places were traveled each day where no connectivity was available. My cell phone was mostly used for pictures, with the “No service” text at the top while in most of the national parks.

    Lots of hiking, and some horseback riding. My wife even managed to get me on a horse one day.

    IMG_20180802_113519

    It was nice to get away, and a little strange to arrive back in a place with more concrete and people than trails and wildlife.

    Going through email and quite a few requests that came in over the last two weeks, as well as starting to prep for SQL Saturday Baton Rouge this weekend. Back in the saddle, as they say, very quickly this week.

  • Will Terminators Be Required?

    I was looking at an article the other day and noticed that there was a CTE sample with the semicolon on the line before the code. I’ve been seeing this convention for years, starting your CTE with a semicolon because people aren’t sure this will get dropped in a batch with other code. It’s not that the CTE needs this, but the previous statement needs to be terminated. There are a few other T-SQL constructs that require any previous statements to be terminated, and as a result, we have a series of strange publishing conventions for sample code.

    I really wish that the language designers had thought this through and stopped trying to overload and reuse keywords. We could have avoided this with a simple CTE language element to indicate the structure. I know, I know, there are other considerations, but this seems annoying. I’m sure that the addition of the CTE fully expected that at some point semicolons would be required for all code.

    Brent wrote about this a few years ago. The Syntax page for T-SQL currently says this about the semicolon: “Transact-SQL statement terminator. Although the semicolon is not required for most statements in this version of SQL Server, it will be required in a future version.” There is no shortage of confusion about where terminators might be required and how to structure code, partially because SQL hasn’t ever used terminators and the evolution of the language has been a bit inconsistent with regard to structure.

    These days it seems that nothing will ever be removed. It appears that nothing else will be deprecated in this age of cloud software and feature toggles.I suspect at this point that we’ll see features wither in the codebase, not receiving future development if Microsoft doesn’t see them as valuable, living in limbo forever.

    I don’t think we’ll ever see terminators required, and as the amount of legacy code grows, it becomes less and less likely they will become mandated.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Republish: Is SQL Server Mature?

    Last day of holiday, so republishing Is SQL Server Mature?