Author: way0utwest

  • 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

  • The Full Stack DBA

    The last couple of years have seen the job title “full stack developer” posted quite often. With the popularity of DevOps, companies are hoping to hire a developer that can work on the database, understand some networking, and continue to build front end applications. In my career, I’ve done all of this while being just titled a programmer, but apparently with more specialization these days, some want to differentiate themselves as being able to do it all.

    I saw this tweet from Erin Stellato, asking if people manage multiple items. Specifically, she asks about “the virtualization, the server admin, the storage, and system security”. No networking, firewalls, etc. in there, but I’ll add those in as well. This week, can you answer this question:

    Are there any of you full-stack DBAs? 

    By that I mean you work on more than the database. Do you manage storage at all? Are you a domain admin with AD responsibilities? Do you manage applications or perform some development? Is there any networking in your daily work?

    I’ve actually done all of these before. At one startup, my primary responsibility was a database developer and administrator, but I had AD rights and needed to help our sysadmin with Exchange and various other servers. I setup and configured our T-1 line to the co-location facility, and explained how to get two NICs in our SQL Server working so that backups and office access didn’t interfere with application access from our web site. I even had to help build new network cables one day.

    In a few jobs, I’ve actually been a domain admin, even though I was primarily a DBA. That was because we shared responsibilities and on-call on the team. Even though my primary work was with databases, I ended up helping work on other systems at times. To me, these were welcome distractions and also chances to build knowledge that was useful in troubleshooting and narrowing down the scope of problems.

    Are any of you still doing that today? Whether you are or not, let us know what types of responsibilities you have at work.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Only One New Shirt in 2018

    Usually I get a few shirts each year, and may donate/give away a few others. However, in 2018, I only got one new shirt, and didn’t even get time to monogram it. Here it is from #SQLintheCity in May.

    32873712_10215886774711160_2254488192629604352_o

    This was an Intel promotional shirt, with their SSDs and older, white USB web cams on it.

    I got a promotion from the place I use, so I’m thinking to try and get a couple new ones for next year. The Wild West and World Traveler shirts are tempting. Though, maybe the National Parks one is good since I made it to 3 parks this past year.

  • Spend More on Security

    In technology, quite a few companies are doing well. In fact, it’s a regular race among Apple and Microsoft to see who’s the world’s more valuable company. However, quite a few other companies in other industries are also doing very well. Many have reported strong earnings in the last couple years. Many of those same companies have had data breaches.

    I saw this tweet from Buck Woody, which says ” Another day, another breach. C’mon companies, get your act together. Spend a bit of that record profit on security. We’re tired of this.”

    I agree. As someone who’s stayed at an SPG hotel, I’d guess my data has been leaked. I’m also guessing that my credit card has been changed since then, since I think I end up changing them once a year because of some data breach. Still, I think that shouldn’t be a habit I have.

    Companies need to spend more than “a bit” on security. They need to better train their IT staff on secure coding and configuration as well as on tools to support those habits and processes. They also need to devote some time and money to fixing past security issues. No system should be immune from patching because of fears that an application stops working. Either internal developers need to test better, or vendor contracts need to specify that software purchased will support platform security patches, which often means the vendors need to ensure that service packs and patches don’t break their products.

    We need to demand more as consumers and technical people, including demanding more of ourselves. Building secure systems is hard. Writing secure code requires we change habits and sometimes do a bit more work. It’s something we all need to learn to do better.

    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.