Thank you Chris Yates (B | T) for hosting this month’s T-SQL Tuesday party. For those of you that do not know T-SQL Tuesday was started by Adam Machanic (B | T) in 2009. If you feel like hosting 1 of these monthly events drop Adam a line. This month’s topic is Something New Learned.
Earlier this year I embarked on a new direction with my career that goes well with this topic. I have had to and I am still learning many new things and I will be constantly learning new things. If I am not then I will not be able to continue to grow with my professional career. Reflecting on these many things that I have learned and still learning I will focus on 1 topic for this T-SQL Tuesday Party Post.
PowerShell has been around a little while now and we are up to Version 5.0. Now I have not ventured past 2.0 and I know some of the PS guys and girls are screaming at me saying get up with the times. I will have to spend some time looking at the new versions and look at updating my scripts but making sure that they are still suitably compatible with various previous Operating Systems so as when using them on client sites that they still work and retrieve the information that I need to retrieve. I am not going to talk about any of the features that are available in the various versions but instead going to have a look at some different approaches to scripting with PowerShell to achieve an outcome.
I do not claim to be a PowerShell expert but it has definitely made my life easier with different tasks I have had to undertake in a SQL Server environment. I have had some help from others around learning the ropes and like always, as I have progressed the code has improved and being able to do more and more with less. However the point of this post is to take you through a scenario.
Regardless of the tool being used the outcome is a working script or set of scripts to achieve the agreed outcome. The approach I have been using for my scripts is a framework learned from others to allow for maximum code re-use and depending on the desired outcome to cater for many different combinations that could be used. To help achieve this the use of configuration files to allow for the various combinations to be driven by the values required. Now all of the scripts had logging and create log files to allow for troubleshooting but also for post implementation confirmations. Some recent feedback around this was it was far to complicated to troubleshoot in the event of a problem.
Instead of being able to cater for the various options, the preferred approach was to reduce the details in the configuration files, reduce the use of a framework, perform a little more hardcoded pieces in the scripts specific per each environment being implemented into. This makes for multiple sets of the same scripts but can make it easier to troubleshoot in the event of issues.
From this experience Something New I learned was to sit back and evaluate the scenario and how I could potentially use bits and pieces from both approaches? I believe that they both have value and depending on what the desired outcome is sometimes a quick and nasty script can achieve the same as one that has been created and tested and provides greater re-use. Which way will I go? Decision is still out.
There is always more than one way to achieve the outcome and I guess the decision comes down to what you feel comfortable providing for your employer.
Leave a Reply