Tag: syndicated

  • tSQLt tests for Day 5 Advent of Code 2017

    This is day 5 of the Advent of Code 2017. If you want to read about the puzzles, start with Day 1.

    As I worked through the puzzles, I decided that I should be testing using their test sets and solving the issues that way. This lets me use the sample data, but also add in my own sets to cover strange situations.

    Here are the tests that I used for each part.

    Part I

    For part 1, only a short test is needed. Since we’re looking for a scalar value, I could easily just added an INT variable for the actual and expected values. I set this to the value given in the problem.

    Then I fake the table and insert the test set. From here, I can call my proc that implements the algorithm and get the result value.

    EXEC tsqlt.NewTestClass @ClassName = N'tDay5';
     GO
     CREATE OR ALTER PROCEDURE tDay5.[test day5 a initial set]
     AS
     BEGIN
    
    -- Assemble
     DECLARE @actual INT = 0, @expected INT = 5;
    
    EXEC tsqlt.FakeTable @TableName = N'Day5' , @Identity = 1
     INSERT Day5
     VALUES
     (0 ), (3), (0), (1), (-3);
    
    -- Act
     EXEC @actual = SolveDay5a;
    
    -- Assert
     EXEC tsqlt.AssertEquals @Expected = @expected, @Actual = @actual, @Message = N'Failed to account'
    
    END

    Part II

    The test is the same, just calling a different procedure that implements the part II algorithm.

    CREATE OR ALTER PROCEDURE tDay5.[test day5 initial set]
     AS
     BEGIN
    
    -- Assemble
     DECLARE @actual INT = 0, @expected INT = 10;
    
    EXEC tsqlt.FakeTable @TableName = N'Day5' , @Identity = 1
     INSERT Day5
     VALUES
     (0 ), (3), (0), (1), (-3);
    
    -- Act
     EXEC @actual = SolveDay5b;
    
    -- Assert
     EXEC tsqlt.AssertEquals @Expected = @expected, @Actual = @actual, @Message = N'Failed to account'
    
    END
  • SQL in the City is coming Feb 28

    The next edition of the SQL in the City broadcast is coming Feb 28, and I’m planning travel now to head back to the UK for the event. The schedule is up on the Redgate Hub Livestream page.

    This edition has lots more GDPR/security/masking content as well as updates on the new products.

    Mark the date on your calendar, let your boss know it’s a training day, and get some friends together to join us for the day.

  • tSQLt Tests for Advent of Code 2017 Day 4

    This is day 4 of the Advent of Code 2017. If you want to read about the puzzles, start with Day 1. As I worked through the puzzles, I decided that I should be testing using their test sets and solving the issues that way. This lets me use the sample data, but also add in my own sets to cover strange situations.

    Here are the tests that I used for each part of day 4.

    Part I

    This is a fairly simple test. I’m returning a result set since the solution is a single query, but this is really a scalar. In this cas,e I’ll create a one row, one column expected table and then get the results from my solution (inside a proc) and insert into Actual.

    The rest is standard tSQLt testing framework. Fake a table, enter data.

    CREATE OR ALTER PROCEDURE tDay4.[test Day4a sample data]
    AS
    BEGIN
         -- Assemble
         EXEC tsqlt.FakeTable @TableName = N'Day4';
         
         INSERT dbo.Day4
    (
         passphrase
    )
    -- SQL Prompt formatting off
    VALUES
        ('aa bb cc dd ee' )
      , ('aa bb cc dd aa')
      , ('aa bb cc dd aaa')
    
    -- SQL Prompt formatting on
        CREATE TABLE #Expected (valid INT);
        INSERT #Expected
        ( valid)
        VALUES
        (1  );
        SELECT *
         INTO #actual
         FROM #Expected AS e
         WHERE 1 = 0;
    
    
         -- Act
       INSERT #actual
        EXEC dbo.Day4_a;
    
        -- Assert
         EXEC tsqlt.AssertEqualsTable @Expected = N'#Expected' ,
                                      @Actual = N'#Actual' ,
                                      @Message = N'Incorrect number of valid passphrases';
         
         
    END
    GO
    
    EXEC tsqlt.run 'tDay4.[test Day4a sample data]';

    Part II

    This is the same as part I, but I change the inputs and results.

    CREATE OR ALTER PROCEDURE tDay4.[test Day4b sample data]
     AS
     BEGIN
     -- Assemble
     EXEC tsqlt.FakeTable @TableName = N'Day4';
    
    INSERT dbo.Day4
     (
     passphrase
     )
     -- SQL Prompt formatting off
     VALUES
     ('abcde fghij' )
     , ('abcde xyz ecdab')
     , ('a ab abc abd abf abj')
     , ('iiii oiii ooii oooi oooo')
     , ('oiii ioii iioi iiio')
    
    -- SQL Prompt formatting on
     CREATE TABLE #Expected (valid INT);
     INSERT #Expected
     ( valid)
     VALUES
     (3  );
     SELECT *
     INTO #actual
     FROM #Expected AS e
     WHERE 1 = 0;
    
    -- Act
     INSERT #actual
     EXEC dbo.Day4_b;
    
    -- Assert
     EXEC tsqlt.AssertEqualsTable @Expected = N'#Expected' ,
     @Actual = N'#Actual' ,
     @Message = N'Incorrect number of valid passphrases';
    
    END
     GO
    
    EXEC tsqlt.run 'tDay4.[test Day4b sample data]';
  • Finding the Default Path with dbatools

    I really like the dbatools project. This is a series of PowerShell cmdlets that are built by the community and incredibly useful for migrations between SQL Servers, but also for various administrative actions. I have a short series on these items.

    It’s been awhile since I worked on any dbatools learning with holidays and travel. I find these cmdlets to be really handy, and if I had to manage a large estate of instances, they would be invaluable.

    I ran across Get-DbaDefaultPath on another blog, and thought this would be a handy little item to have. It is.

    I know the project changes, so I ran an update-module to get the latest items first. Then I tried the cmdlet. I ran a simple query against a local instance, and I quickly get the details, my instance and the Data, Log, Backup, and ErrorLog locations.

    2018-01-15 11_54_46-cmd - powershell (Admin)

    This is handy information, especially as I often have multiple instances (same or different machines) and I may want to make sure I don’t put a database on a small drive, or I need to find out where a backup is (or errorlog).

    The normal way of getting this information for me has been to right click the instance in SSMS, possibly connect first, get the properties, and look at the panels in the dialog. It works, but it’s slow.

    This is a much quicker way for me to find out paths, which  just makes admin easier. With tab completion, this will be the new way I find paths.

    The advantages of using this to gather paths, check sizes, and do some scripting to find files, copy them, make decisions about where to create databases, etc. are many. I can see this would be a great way to build scripts that include some decision making that adapts a simple process to new environments.

    If you haven’t tried dbatools, do it today. It’s a fantastic administration tool for your toolbelt.