Category: Blog

  • The 2019 Learning Goals

    As mentioned in my editorial, I plan on working through books this year for some extra learning. Certainly I’ll still use Pluralsight, websites, and more learn some things, but I want to get through at least 6 books this year and practice those skills. Six seems doable. Eight would be great. Twelve is unlikely and four is a failure. You can see this in my amazing, homegrown career skill thermometer.

    2018-12-20 13_31_33-Presentation1 - PowerPoint

    In any case, my goal tracking will be looking at how I get through books. Here are the ones on my list for now, in no particular order. They’re just listed in the order I bought them during the CyberWeek sale.

    I’m going to start with Pro SQL Server on Linux and go from there. I may add other books, or change mid year, depending on what I find as I go through these books.

  • Testing SQL in the Advent of Code

    I like participating in the Advent of Code each year, though my participation often varies wildly as life gets in the way. Still, trying to solve some programming challenges is a good way of practicing your skills. If you’re competitive, you can try and see how quickly you can solve things and get onto the leaderboard.

    One note, if you enjoy the challenges, support the cost of running the site. Sending $5 would make a difference to what I’m sure is a decent amount of effort and some costs. Plus, I’d certainly be happy to buy the author some sushi if I were sitting next to him, so why not send something during the holidays.

    This year’s challenge is over, but you can still work through the challenges. In my case, I’ve gone through a few and hope to get to more in a few spare moments.

    Testing Day 2

    One of the things I’ve done in the past is see a challenge and then start to write some code. I’ve worked through the puzzles in PoSh, Python, and SQL, sometimes all three. When I think I’ve solved it, I often enter a result, which is wrong, and then code some more, repeating as needed.

    This isn’t different from what I’ve done as an employee for a company, but I’ve also realized that the subtle design specification is sometimes mis-interpreted by me. In that case, I’ve essentially been bothering the “QA” people for no reason. It’s an application in this case, but still.

    It would be better to have inputs and outputs specified and checked by the computer, which is way better at checking than I am. I decided to set up test harnesses after Day 1 (which was really easy) for the problems. Here’s Day 2.

    Puzzle A

    The first part of Day 2 is a puzzle about letters, asking you to compute a checksum based on whether any letters are repeated. This isn’t a complex set of instructions, but it would be easy to make a mistake. Across any number of sets, a human might have problems verifying the actual results.

    Since the answer here is a single value, this lends itself to a test. I decided to start by creating a table and then loading the input data into the table. That’s something I often do, so the basics here were:

    CREATE TABLE dbo.Day2
    ( Boxnumber INT
    , boxid VARCHAR(100)
    )
    GO
    INSERT dbo.Day2 (boxnumber,boxid)
    SELECT  ca1.ItemNumber,
             ca2.Item
    FROM    OPENROWSET(BULK 'e:\Documents\GitHub\AdventofCode\2018\Day2\input.txt', SINGLE_CLOB) dt(FileData)
    CROSS APPLY dbo.Split(dt.FileData, CHAR(10)) ca1
    CROSS APPLY (VALUES(REPLACE(ca1.Item, CHAR(13), ''))) ca2(Item);

    Now that I had data, I can write a test. I like to use tsqlt, so I started there. Since I want something to test, I decided to start with a procedure that will hold my solution. Since I’ll code here, I can stub this out.

    CREATE OR ALTER PROCEDURE Day2a
    AS
    BEGIN
         DECLARE @i INT = 1;

    -- Solution goes here
     
    RETURN @i
    END

    With this set up, we can now build a test. The basic outline for a test is Assemble an environment, Act on your code, Assert your results. Let’s follow this template.

    The Assemble is easy. I’ll fake out my table of values and insert the test section from the calendar. I’ll also add the expected result, which is given in the puzzle as 12.

    CREATE OR ALTER PROCEDURE tsqltests.[test Day2a]
    AS
    BEGIN
         ---------------
         -- Assemble
         ---------------
         DECLARE
             @expected INT = 12
           , @actual INT;
         EXEC tsqlt.faketable @TableName = 'Day2', @SchemaName = 'dbo';
         INSERT dbo.Day2
             (
                 Boxnumber
               , boxid
             )
         VALUES
             (1, 'abcdef')
           , (2, 'bababc')
           , (3, 'abbcde')
           , (4, 'abcccd')
           , (5, 'aabcdd')
           , (6, 'abcdee')
           , (7, 'ababab');

    The Act part is easy. I’ll call my procedure and get the result back.

    ---------------
    -- Act
    ---------------
    EXEC @actual = dbo.Day2a;

    The Assert part is also easy. I’ll just compare my actual result to what I expected.

    ---------------
    -- Assert   
    ---------------
    EXEC tSQLt.AssertEquals
         @Expected = @expected
       , @Actual = @actual
       , @Message = N'An incorrect checksum calculation occurred.';

    Once this is done, I’ll run it and it fails because my stub proc returns 1. Now to code the solution, which I can easily check by running my test. I can verify things work with a first change to my procedure.

    CREATE OR ALTER PROCEDURE Day2a
    AS
    BEGIN
         DECLARE @i INT = 1;
    SELECT @i = 12
    RETURN @i

    GO

    EXEC tsqlt.run 'tsqltests.[test Day2a]';

    That’s it, and the solution is to split out the box IDs, count the letters, and where there are repeats, tally those up.

    Puzzle B

    The second part of the puzzle is always a nice twist on the first part. In this case, I get a new set of IDs, which vary by a single character.I need to pick those two box IDs and return the common ones. A new solution needed, but only a slight change to the test.

    First, we change the Assemble section because we have new results and inputs.

        ---------------
         -- Assemble
         ---------------
         DECLARE
             @expected VARCHAR(26) = 'fgij',
             @actual   VARCHAR(26);

        EXEC tsqlt.faketable @TableName = 'Day2', @SchemaName = 'dbo';
         INSERT dbo.Day2 (Boxnumber, boxid) VALUES
    (1, 'abcde'),
    (2, 'fghij'),
    (3, 'klmno'),
    (4, 'pqrst'),
    (5, 'fguij'),
    (6, 'axcye'),
    (7, 'wvxyz')

    Next, I need to change the ACT section. Since I can’t return a string from a procedure, I could use a function, but I’ll just add an OUTPUT parameter to my Act.

    ---------------
    -- Act
    ---------------
    EXEC dbo.Day2a @actual OUTPUT;

    Lastly, I change the proc.

    CREATE OR ALTER PROCEDURE Day2b
       @r VARCHAR(50) out
    AS

    That’s it.

    Good luck solving the puzzles.

  • My SQL Server Travels in 2018

    It’s the end of the year, and I’m looking back at the events and travels I’ve had this year. I keep a list of travels on my blog for speaking as a kind of Speaking CV, and United (my primary airline) provides me with a summary of travel each year.

    Since I’m planning and looking forward to 2019, I thought I’d recap a few of my travels.

    New Events and Places

    Every year I try to visit some new places and events, getting the chance to meet new people and learn about events and places. There are so many to see and attend that this is a never ending goal, but that’s part of the fun.

    New places I visited this year: Cork, Pittsburgh, Nashville, Jacksonville (personal), and Hong Kong (personal).

    New Events for me: ISACA Ireland, Music City Tech, Microsoft Inspire, SQL Sat Pittsburgh, Certified InfoSec.

    I did a few new virtual talks, even though I don’t really enjoy these. I like feedback from in person talks but the Milwaukee and Queensland user groups got me to speak.

    Revisiting Fond Memories

    I was lucky enough to get to revisit a number of places this year. Of those, I enjoyed getting to do some live SQL in the City events, in addition to the streamed ones. I did 4 of each, so a good SQL in the City year.

    It was also great to get back to Baton Rouge, Louisville, Los Angeles, Colorado Springs, Boulder, Oslo, and Cambridge for events. Those are some of my favorite places for SQL events and I’ve been at all of them 3 or more times.

    I was also luck to spend a few days in Washington DC and New York City, two amazing places in the US.

    Of course, as usual, London was the most visited destination. 6 times in 2018, and probably close to 40 trips there in my life.

    Missed Out

    I missed out on SQL Bits in 2018, the first time in quite a few years. Unfortunately this conflicted with other commitments at home, and will again in 2019. Hopefully that will change in 2020.

    I also skipped the VS Live, Dev Connections, Ignite, Build, and SQL Intersection events. I’ve enjoyed those over the years, but this wasn’t the time to go, and next year might not be either. We’ll see what happens.

    All in all it was a great year speaking, and with travel that was manageable. Hopefully that continues in 2019.

  • Identity Gaps–#SQLNewBlogger

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

    Many people think that that an identity property will ensure a consistent, increasing numerical value. I ran across this tweet that indicates that situation.

    2018-12-21 12_13_51-Krista on Twitter_ _#SQLHelp Is there any other reason (other than a DELETE) for

    This isn’t really true, for many reasons, but in this post I’ll look at the possible reasons we get gaps in identity values.

    Normal Operation

    Let’s start with a basic table that contains an identity value. I’ll use this code:

    CREATE TABLE dbo.SalesOrderHeader
    ( OrderKey INT IDENTITY(1, 1)
    , CustomerName VARCHAR(30)
    )
    GO

    Now I can insert a few rows. Note that the results shown below the code will contain increasing values for the OrderKey.

    INSERT dbo.SalesOrderHeader (CustomerName) VALUES ('Andy')
    INSERT dbo.SalesOrderHeader (CustomerName) VALUES ('Brian')
    INSERT dbo.SalesOrderHeader (CustomerName) VALUES ('Steve')
    INSERT dbo.SalesOrderHeader (CustomerName) VALUES ('Anna')
    GO

    Each of these inserts is a separate transaction, and they cause the identity to increment.

    2018-12-21 12_04_17-SQLQuery5.sql - Plato_SQL2017.sandbox (PLATO_Steve (59))_ - Microsoft SQL Server

    Deleting Rows

    This is noted in the tweet as a cause, but let’s test this.

    One of the common ways that we get gaps in identity values is when rows are deleted. Let’s remove the row with Steve in it.

    2018-12-21 12_06_46-SQLQuery5.sql - Plato_SQL2017.sandbox (PLATO_Steve (59))_ - Microsoft SQL Server

    I clearly have a gap in OrderKey here now. What happens if we add a new row? The identity value is built for (some) efficiency and doesn’t fill the gap. Only the next value is kept. We insert a row and get a 5.

    2018-12-21 12_08_00-SQLQuery5.sql - Plato_SQL2017.sandbox (PLATO_Steve (59))_ - Microsoft SQL Server

    As a side note, there is no index on this table, and no ORDER BY clause, so you can clearly see that there isn’t a reason why I should expect the ORDERKEY column to be returned in numerical or even insert order.

    The Rollback

    One of the more common occurrences with inserts is a problem with the value. For example, in this table, I have allocated 30 characters. What happens if I run this code?

    INSERT dbo.SalesOrderHeader (CustomerName) 
       VALUES ('A Really Long Name Van Something The Third')

    I get an error, which is shown here.


    Checking the table, I have no value:

    2018-12-21 12_11_17-SQLQuery5.sql - Plato_SQL2017.sandbox (PLATO_Steve (59))_ - Microsoft SQL Server

    Let’s insert a new value and see.

    2018-12-21 12_12_00-SQLQuery5.sql - Plato_SQL2017.sandbox (PLATO_Steve (59))_ - Microsoft SQL Server

    We get a gap. The value “6” was skipped because of the error. The identity was allocated, but the rollback of the transaction due to the error did not rollback the identity sequence.

    Reseeding the Property

    One of the other ways to miss a value is directly reseeding the table. I can use the DBCC CHECKIDENT function to accomplish this. In my case, let’s run this code and set the identity value to 20.

    DBCC CHECKIDENT(SalesOrderHeader, RESEED, 20)
    GO

    Now I can insert new values and I’ll get these results.

    2018-12-21 12_17_28-SQLQuery5.sql - Plato_SQL2017.sandbox (PLATO_Steve (59))_ - Microsoft SQL Server

    The identity value was set to 20 and the next insert will increment this and take 21, leaving a gap from 8 to 20.

    Be Careful

    Don’t depend on the identity property to give you uniqueness, consecutive values, or avoid duplicates. It is up to you to code properly to account for these values.

    SQLNewBlogger

    This post came about from helping someone understand the problems and limitations. I wrote this in about 20 minutes (with setup and testing) to ensure that I understood what I was explaining to someone.

    You could write something similar to show that you know the ways in which identity works.