Today we have a guest editorial from Andy Warren as Steve is away on vacation.

I was recently speaking with a DBA about what areas we were each targeting for career skills. I have been doing some PowerShell learning and mentioned that. He replied that “PowerShell intimidates me”. Honest and courageous to say, in my view. I was thinking afterward that I bet many of us had similar thoughts, and it was worth exploring more. Why have so many of us been slow to invest time in learning PowerShell? Why have I been so slow to do so?

Looking back, I didn’t pay much attention to the launch of PowerShell. It felt at the time like typical Microsoft hyperbole and more than that, it felt like one more thing to learn when I had a whole lot of other learning to do. I think it was hyperbole, but things change. You might think of PowerShell v1 as SQL 7 and PowerShell v3 as SQL 2005. Both were usable, but SQL 2005 was a whole lot more usable. [We’re at PowerShell v5 now]

I felt then, and now, that most of the PowerShell advocates didn’t make effective cases for why a DBA would find it valuable to learn. For example, one common theme was that you could use SMO with PowerShell. Interesting if you were using SMO via another language, but not if you weren’t using it at all. We have significant tools at our disposal; a strong scripting(ish) language in T-SQL, SSIS for moving data and files, a configurable, if cumbersome installer for SQL Server. What problem did PowerShell solve better than those? Honest enthusiasm often failed to show DBA’s interesting patterns that they would really use.

SQL Server didn’t do PowerShell any favors either. It was ‘baked in’ to SQL 2012, except it was tied to PowerShell v2 and if you wanted to run v3 you had to launch the script from the exe. You could run PowerShell as a job (useful), but SSMS didn’t then, or now, really show a DBA the places and ways that it might make life better and/or more repeatable.

PowerShell is built on objects, which makes it both cool and super powerful…if you understand objects, and more so, if you’ve written some code in the .Net world. If you haven’t, well, it’s just more opaque than ever. Just saying “objects” adds a lot of fear to the conversation.

It is C#’ish. It has “$” everywhere instead of “@” that we all know is the correct way to indicate a variable. You can write functions, but the use of RETURN is optional and functions return all output, not just the result. You can, if you wish, chain together statement after statement via the pipeline to create a close to un-understandable-one-liner, especially if you use aliases that only the gurus have memorized.

All valid, to some degree, but not the real issue. They say that when all you have is a hammer all problems look like nails. Most of our problems are nails and our T-SQL hammer works well for them. If you’re pragmatic about what you learn (and you should be), you have to evaluate whether learning PowerShell is more important than learning anything else, or where it goes on the list.

All of those contributed in some way to me not taking time to dig in. Last year learning it finally made it to the top of my list for three reasons; I had time, it felt like a big gap in my game, and I had a small project that seemed liked a good fit.

I can’t tell you that learning PowerShell is the right thing for you. I can tell you that if you look past the syntactical differences it’s a nice language. I can tell you that I think learning it to a reasonable degree is a 100 hour investment. I can tell you that being able to say “I know PowerShell” is a nice card to play during an interview, but probably more of a tie-breaker than a job-getter. I can tell you that it’s felt good to learn something new, even if it frustrated me more than once!

I shared much of that with my friend, along with this – the few steps up the learning curve are always hard. Feeling reluctant or intimidated is normal, but once you start that doesn’t last long. The trick is deciding to start, and then finding a good book, video, class, or mentor to help get you through that first phase.

Editor's note: We have a Stairway to Powershell and the PowerShell Tool Time series here to help you get started.

Join the debate, and respond to today's editorial on the forums

Unique constraints on strings pad with trailing spaces when comparing values.

Although 'A123 ' and 'A123' are not exactly the same, the SQL-92 specification requires padding of character strings used in comparison, so that thei lenghts match. This results in 'A123' being treated as 'A123 ' and therefore matches an existing row in the table, hence why the primary key cannot be created.

Ref: MSKB-https://support.microsoft.com/en-us/kb/316626

» Discuss this question and answer on the forums