Category: Blog

  • The Lighter Side–Morning at the Redgate Office

    I was chatting recently with someone about the coffee machines at Redgate Software. We have 4 of them, all located in the downstairs lobby, which provide a way for people to take a break from their desk or between meetings, and wander down for a cup.

    They are great machines, and I show some video recently to share with a few friends,

    I visit this machine often when I’m in the office, going between lattes and black coffee throughout the day.

  • Just a week to SQL Saturday in Pensacola

    Next week is  SQL Saturday #491 in Pensacola. I’ll be there, along with a number of other great speakers. It’s free SQL Server training, and a great place to vacation. There are a couple pre-conference sessions available as well if you are looking for some training.

  • A Basic Recursive CTE and a Money Lesson

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

    When I was a six or seven year old, my Mom asked me a question. She asked if I’d rather have $1,000,000 at the end of the month, or a penny on day 1, with the note that each day of the month, she’d double what I’d gotten the first day. Doing quick math in my head, $0.01, $0.02, $0.04, etc, I said a million.

    Was I right? Let’s build a recursive CTE.

    Recursion is an interesting computer science technique that stumps lots of people. When I was learning programming, it seemed that recursion (in Pascal) and pointers (in C), were the weed out topics.

    However, they aren’t that bad, and with CTEs, we can write recursion in T-SQL. I won’t cover where this might be used in this post, though I will give you a simple CTE to view.

    There are two parts you need: the anchor and the recursive member. These are connected with a UNION ALL. There can be multiple items, but we’ll keep things simple.

    I want to first build an anchor, which is the base for my query. In my case, I want to start with the day of the month, which I’ll represent with a [d]. I also need the amount to be paid that day, which is represented with [v]. I’ll include the $1,000,000 as a scalar at the end. My anchor looks like this:

    WITH myWealth ( d, v)
    AS (

    — anchor, day 1
    SELECT
    ‘d’ = 1
    , ‘v’ = CAST( 0.01 AS numeric(38,2))
    UNION ALL

    Now I need to add in the recursive part. In this part, I’ll query the CTE itself, calling myWealth as part of the code. For my query, I want to increment the day by 1 with each call, so I’ll add one to that value.

    SELECT
    myWealth.d + 1

    For the payment that day, it’s a simple doubling of the previous day. So I can do this a few days: addition or multiplication. I’ll use multiplication since it’s easier to read.

    SELECT
    myWealth.d + 1
    , myWealth.v * 2

    My FROM clause is the CTE itself. However I need a way to stop the recursion. In my case, I want to stop after 31 days. So I’ll add that.

    UPDATE: The original code (<= 31) went to 32 days. This has been corrected to stop at 31 days.

    FROM
    myWealth
    WHERE
    myWealth.d <= 30

    Now let’s see it all together, with a little fun at the end for the outer query.

    WITH  myWealth ( d, v )
    AS (
    — anchor, day 1)
    SELECT
    ‘d’ = 1
    , ‘v’ = CAST(0.01 AS NUMERIC(38, 2))
    UNION ALL
    — recursive part, get double the next value, end at one month
    SELECT
    myWealth.d + 1
    , myWealth.v * 2
    FROM
    myWealth
    WHERE
    myWealth.d <= 31
    )
    SELECT
    ‘day’ = myWealth.d
    , ‘payment’ = myWealth.v
    , ‘lump sum’ = 1000000
    , ‘decision’ = CASE WHEN myWealth.v < 1000000 THEN ‘Good Decision’
    ELSE ‘Bad decision’
    END
    FROM
    myWealth;

    When I run this, I get some results:

    2016-05-17 18_48_04-Start

    Did I make a good choice? Let’s look for the last few days of the month.

    2016-05-17 18_48_16-Start

    That $1,000,000 isn’t looking too good. If I added a running total, it would be worse.

    SQLNewBlogger

    If you want to try this yourself, add the running total and explain how it works.

  • Changing Your PASS Credentials

    I got an email today from PASS, noting that credentials were changing from username to email. That’s fine. I don’t really care, but I know I got multiple emails to different accounts, so which account is associated with which email?

    I clicked the “login details” link in the email and got this:

    2016-05-24 12_31_06-PASS _ User Login

    Not terribly helpful, but I was at least logged in. If I click my name, I see this:

    2016-05-24 14_09_26-Movies & TV

    Some info, including the email, which I’m not sure is linked to the email I clicked on, or is based on browser cookies. However, there’s no username here.

    If I click the edit profile link, I get more info, but again, no username. No way to tie back anything I’ve done in the past to this account.

    2016-05-24 14_12_28-Movies & TV

    I have always used a username to log into the SQLSaturday site, so I went there. On this PASS property, I’ve got my username.

    2016-05-24 14_14_46-Movies & TV

    If I click the username, I go back to the PASS site, to the MySQLSaturday section, but again, no link to this username. However I realize now which email is related to which username.

    Hopefully the others will go dormant soon and I won’t get multiple announcements, connectors, ballots, etc.

    The point here isn’t to pick on PASS as much as it is to point out some poor software and communication preferences. Changing to email from username (or vice versa) can be a disruptive change. I’d expect the email would include some information on username and email relation, or at least username since it was sent to a specific email. That would allow me to determine where I might need to contact PASS to update things, or which username was affected for me.

    I’d also expect that the username to be stored somewhere and visible on the site. Even if this isn’t valid login information, why not just show it? When we migrated SQLServerCentral from one platform to another, we kept some columns in the database that showed legacy information. This information wasn’t really used, but it did help track down a few problems we had with the migration. Having a bit of data is nice, and it doesn’t cost much (at least in most cases).

    This wasn’t a smooth process, though not too broken for me. I like that PASS sent the communication, and I’m glad the old method still works. I logged in with username today. I wish there was a bit more consistency between PASS applications, and that they included a date when username will no longer work. I also hope they update their testing (or test plan) with any issues they discover this week, so the problems aren’t repeated.