Category: Blog

  • A New Word: 1202

    1202– n. the tipping point when your brain becomes so overwhelmed with tasks you need to do, you feel too guilty to put anything off until later, prioritizing every little thing at the top of the list, leaving you immobilized.

    Not quite a word, but still a fun concept. Do you get so overwhelmed you prioritize everything on the list? Are you immobilized?

    I don’t and I’m not. I don’t get 1202.

    I go get overwhelmed, but I still can add things to my list, or lists. Things to learn, things to fix, etc. Often, however, I’m not immobilized here, even if I prioritize some things. What I might do if I’m overwhelmed is either buckle down and do one thing, or give up and do something completely different.

    FWIW, this comes from the lunar descent of Apollo 11 where the 1202 alarm was the one the computer set off when there was too much data to process.

    From the Dictionary of Obscure Sorrows

  • The Basics of TRY CATCH Blocks–#SQLNewBlogger

    I was working with a customer and discussing how to do error handling. This is a short post that looks at how you can start adding TRY.. CATCH blocks to your code.

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

    TRY CATCH

    This is a common error handling technique in other languages. C# uses it, as does Java, while Python has TRY EXCEPT. There are other examples, but these are good habits to get into when you don’t know how code will behave or if there is something in your data or environment that could cause an issue.

    In SQL, I think many of us get used to writing one statement in a query and forget to do error handling, or transactions. However, this can be a good habit as your code might grow and people might add more statements that should execute.

    A classic example of code is someone writing this:

    DECLARE
       @id INT = 2
    , @name VARCHAR(20) = 'Voice od the DBA'
    , @stat INT = 1;
    BEGIN TRAN;
    INSERT dbo.Customer
       (CustomerID, CustomerName, status)
    VALUES
       (@id, @name, @stat);
    IF @@ERROR = 0
       COMMIT;
    ELSE
       ROLLBACK;
    
    

    Note that this does look for an error and then decide what to do. However, we could be better, especially if we wanted to possibly add a second insert or other work. We could do this:

    DECLARE
       @id INT = 2
    , @name VARCHAR(20) = 'Voice od the DBA'
    , @stat INT = 1;
    BEGIN TRY
         BEGIN TRAN;
         INSERT dbo.Customer
         (CustomerID, CustomerName, status)
         VALUES
         (@id, @name, @stat);
         COMMIT
    END TRY
    BEGIN CATCH
         ROLLBACK 
    END CATCH
    
    

    It doesn’t look like much, but this code could easily be enhanced with a better pattern. We can capture the various error messages like this:

    DECLARE
       @id INT = 2
    , @name VARCHAR(20) = 'Voice od the DBA'
    , @stat INT = 1;
    BEGIN TRY
         BEGIN TRAN;
         INSERT dbo.Customer
         (CustomerID, CustomerName, status)
         VALUES
         (@id, @name, @stat);
         COMMIT
    END TRY
    BEGIN CATCH
        DECLARE @ErrorMessage NVARCHAR(4000);
        DECLARE @ErrorSeverity INT;
        DECLARE @ErrorState INT;
    
        SELECT 
            @ErrorMessage = ERROR_MESSAGE(),
            @ErrorSeverity = ERROR_SEVERITY(),
            @ErrorState = ERROR_STATE();
    
        RAISERROR (@ErrorMessage, -- Message text.
                   @ErrorSeverity, -- Severity.
                   @ErrorState -- State.
                   );
    
        WHILE @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRANSACTION;
        END 
    END CATCH
    
    

    In this case, we have a few statements that work with the error, in this case using RAISERROR to raise this. We could also use THROW or add something else. If we had more inserts, like to a child table, we could encapsulate them all here. What’s more, if we had logging, we could log this before the rollback to another system if our logging were not transaction dependent.

    Using TRY CATCH is really just structuring your code differently. Ideally, using something a snippet in SQL Prompt so your developers have an easy way to standardize error handling.

    SQL New Blogger

    This post took me about 15 minutes to structure and test. I looked at a few patterns, and I liked the one in this Stack Overflow answer as a good way to generically implement this structure.

    You could write a similar post showing your next boss how you implement error handling, transactions, anything. Give it a try.

  • Apr 9 Webinar: Accelerating Success: De-risking and Streamlining Releases with Flyway Enterprise

    UPDATE: This moved to Apr 9

    Join me Tuesday, Apr 9 for a webinar, 10:00am CDT. You can register here and then come watch live with questions or get the recording.

    In this webinar, we’ll look at how the Flyway suite of tools can help your team better build and manage database deployments. I love Flyway, and it does a lot of things I was doing in 2001 when DevOps wasn’t even a term and we were releasing every week.

    You can do the same thing, with some of the advanced things Flyway brings to the table that you don’t have to build and maintain.

    • script generation
    • code analysis rules
    • change and drift reports
    • a comprehensive view for impact assessment

    There’s more, but join us on Thursday by registering today

    Tell your friends as well, pass this along, and bring your questions.

  • Book Review: 100 SQL Server Mistakes

    I was approached by Manning Publications and asked to review 100 SQL Server Mistakes and How to Avoid Them. They gave me a free copy of the book (and offered a second one as well), but didn’t put any conditions on my work.

    This is a preliminary review of the EAP version of the book, which is still in progress as of now. If you buy the book, you can get digital chapters as they are written and edited, as well as the final book.

    This is part of a series of book reviews I’ve done on my blog. You can see them all under the book reviews tag.

    100 SQL Server Mistakes

    The book is designed to give you 100 things that people commonly do wrong with a SQL Server instance and/or database, and starts with mistake 0 being that people think

    From there, the book goes into an explanation of the 4Cs diagrams, which are ways of representing systems. This was mildly interesting to me, though less useful when I was reading on my mobile as seeing the details of the diagrams is hard.

    The first few mistakes are on standards. Naming, prefixes, using sp_, and more. I liked this as I think that having some good basics communicate information between team members, or even users of your database for reporting. There are reasons given for why each of these is a mistake, as well as example code to showcase potential issues.

    Data Types are the next set of mistakes, showing common things people do when designing their data model or objects. There is also a few mistakes on database design with common mistakes that people make.

    There are sections for T-SQL mistakes, including error handling as well SSIS mistakes and installation problems. Each of these is grouped together with a variety of common issues that people may run into.

    The version I have of the EAP is 8 chapters, with a few more to come. Overall, this is less a what you should do, and more of a what you shouldn’t do. I like this approach. Aaron Bertrand did something similar with his Worst Practices series. Often we are stuck with certain designs, and we may not be able to implement best practices. However, we should try to avoid worst practices.

    I’d even say that if you have some worst practices, don’t continue them for the sake of continuity or consistency. Start refactoring or at least improving new development.

    This book is a good reference for beginner to intermediate SQL Server developers and administrators, and might even be a good gift for welcoming employees early in their SQL Server journey. Many of these would be guidelines I’d want to implement for  a team.

    If you’re looking for some knowledge to help you avoid producing bad code, check out this book. It doesn’t have all the answers, but it has some good thoughts on code smells and ways to correct them. It might give you inspiration to fix some code in your shop.

    If you want another view, Kevin Feasel has his own thoughts.

    You can pick up the book here: https://www.manning.com/books/100-sql-server-mistakes-and-how-to-avoid-them