Author: way0utwest

  • Exporting a Table to CSV in PoSh–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I saw someone struggling with exporting some data from a table in a CSV, and decided to give it a try. I think there were a few things that were broken, but here is the basic idea.

    The Scenario

    I want to get all the data from a table into a CSV. As a setup, I have a table that looks like this:

    2019-12-02 13_01_11-SQLQuery10.sql - Plato_SQL2017.sandbox (PLATO_Steve (56))_ - Microsoft SQL Serve

    What I’d like is this data in a CSV, with a format like this:

    "CustomerKey","CustomerName","CustomerNameLen"
    "1","Steve","5"
    "2","Andy","4"
    "3","Brian","5"
    "5","Acme, Inc.","10"
    "6","Apple","5"
    "7","IBM","3"
    "1","Steve","5"
    "2","Andy","4"
    "3","Brian","5"

    Let’s make that happen.

    PoSh to the Rescue

    If you have SQL Server and the Powershell module installed, you can use the Invoke-SqlCmd cmdlet. This takes parameters for a query and a server that you want to use. There are other parameters as well, but I’ll keep this simple.

    The parameters I’ll use are a query with three part naming and then an instance. Here is the command:

    Invoke-Sqlcmd -Query "SELECT * FROM [Sandbox].[dbo].[Customer]" -ServerInstance "Plato\SQL2017"

    Now we want to get that data out to a CSV, and we can use the Export-Csv cmdlet for this. For me, I often want to avoid extra work, though in the past, I’d have set the output of the Invoke-SqlCmd to a variable. I don’t need to here, so I can use pipe the output to the cmdlet like this:

    Invoke-Sqlcmd -Query "SELECT * FROM [Sandbox].[dbo].[Customer]" -ServerInstance "Plato\SQL2017" |
    Export-Csv -Path E:\Documents\sql\Customer.csv –NoTypeInformation

    This will create a new file for me, called Customer.csv.

    
    

    2019-12-02 13_15_17-sql

    In here, we have our data.

    2019-12-02 13_01_52-E__Documents_sql__2019Dec02_125737.csv - Sublime Text

    Easy, and quick. You could even type this from the command line, without saving the code.

    SQLNewBlogger

    A quick look at a common task. In this case, I was helping someone, but I’ve had the need to do this myself, and fixing someone else’s code actually taught me something here. I’d use this as a story of solving a problem in an interview with new technology (PoSh).

    Solving the problem was about 10 minutes work, and really, this took about 15 minutes to set up, get working, and clean the code a bit. I also had to change a few of the other issues to make this simpler, but those will be good posts in the future.

  • T-SQL Tuesday Gifts (#121)

    tsqltuesday

    It’s that time of month. I missed last month while traveling, but I wanted to get back in the party. This month, Mala has invited us to talk about the gifts we’ve gotten this year. An easy one for me in 2019.

    Down Under

    The gift for me this year was getting to travel to Australia and New Zealand. I’ve always wanted to go and haven’t been quite able to make it a priority. Last year when I heard we had a Redgate office opening in Australia, I knew this was my chance. We decided to run a few SQL in the City Summit events in 2019 down under and I got to go.

    I was lucky enough to go, and not only attend a few events, but I spent nearly a month in Australia/New Zealand. I spoke at 3 SQL in the City Summits and three SQL Saturdays, which were very enjoyable for me.

    I brought my family along for part of the trip and ended up traveling a little in the middle and taking some holiday. I managed to visit Brisbane, Melbourne, Christchurch, Dunedin, and Queenstown.

    Things went well, and I actually went back to Sydney in September, but just for a couple days. Still, I made the most of it.

    20190926_133919_Burst01

    This was truly a gift for me.

  • Product Platform Teams

    Is infrastructure a product? Should an Ops team start to feel like they are a team involved in building things rather than maintaining them? It’s an interesting idea that is put forth in this blog from Forrester. The piece postulates that the Ops group should be thinking like a product team, just like developers working on an application.

    When a development group moves to a DevOps style of building things, and starts to take some responsibility for the support of their work, what does the Ops group do? If we push infrastructure as code into our VCS, is there much for the Ops group to do?

    I’d argue there still is. From the DBA side, operational staff can help determine what infrastructure is needed, or what changes need to be made. It’s easy to say that devs should add RAM or CPUs, or even another replica, but do they really know when to add them? Or do they just scale everything up? The latter might be easy on people used to writing code, but it’s not necessarily a good idea for the organizational budget.

    Ops staff can still tune systems, add indexes and rewrite code, and give feedback and knowledge to developers to help them understand how to write better code, or infra-as-code code, the first time. There’s also the need to practice and be ready for various DR situations, including the “whoops, I deleted some data”. There are skills that help handle these situations, which are far different from developer skills.

    This is in addition to designing new systems and setting templates for that infrastructure as code that the developers keep in their VCS. There’s also the need to build self-service tools, which might be where Ops becomes a product team. I think that will be necessary, as tooling is important everywhere. I think Operations might even develop other things, like reports requirements that developers don’t have time to build. Ultimately, though, there is still a need for some Ops work, albeit work that ought to be closely aligned, and shared, with developers.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Data for Defense

    It’s a dangerous world out there. Many of us hear about data breaches on a regular basis, and we often blame poor security at various organizations. Certainly there are a lot of silly mistakes made, whether in configuration or the mishandling of data in insecure environments. Security is a tough business, however, and most organizations don’t have the budget to combat all the threats they face, at least not as effectively as a larger organization could.

    I have more sympathy for organizations after reading about the work of some Microsoft security teams that go up against the world’s best hackers on a daily basis. To truly understand the vulnerabilities in software, someone must also understand how to attack it. Those of us that only have a defensive mindset are inherently limited in how we design protective measures.

    There is a group, the Microsoft Threat Intelligence Center (MSTIC), that looks for and tracks hackers around the world, trying to understand how they attack organizations. This is a group of multiple teams looking at nation state attacks, as well as complex software tricks, using the tremendous amount of data they gather from telemetry to analyze the different techniques and vectors used to exploit holes in our systems. They notify customers, letting them know when a customer need to be prepared to defend themselves.

    This is a fascinating read, and one that makes me think that most of our organizations are going to be at cyberwar for the foreseeable future. Already we know that any system on the Internet is likely to be probed and attacked if it has vulnerabilities. Most of us are careful about what we expose, but we also know the weakest link in our organization could cause us issues.

    We do the best we can, but often we do depend on other organizations, like Microsoft, to actively be identifying and helping us understand what to patch or change to protect ourselves. I assume Google and Apple have similar groups, notifying their customers of potential threats. These large vendors are likely the best positioned to help, given all the data they collect about their platforms. Certainly I worry about data privacy with these vendors, but I do think that their massive troves of data on how their software works can also benefit all of us.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.