Category: Blog

  • Back

    It’s amazing to think I’ve been gone 10 days, out of the country. SQL Bits was amazing, and still is the best SQL Server conference in the world I’ve seen. I haven’t been to them all, but this is the best of those I go to.

    Ireland was fantastic, and a very warm welcome for a day of training and then a talk at the Dublin SQL Server User Group. Some really interesting questions for me to blog about and answer in the next few weeks.

    Photo Mar 05, 10 40 37 AM

    I saw some neat SQL Server tips, tricks, ideas, and inspirations, which is always a good thing as it motivates me to do more and learn more as my career progresses.

    And I got a new shirt:

    Photo Mar 05, 4 15 07 AM

    An amazing gift from the crew at SQL Bits. My own speaker shirt. I was quite touched and I really appreciate the effort they went to. I know what I’ll be wearing next year.

    Photo Mar 10, 1 52 58 AM

    A few people were jealous, since the "regular" speaker shirts were blue polos. I guess I stand out a bit from them. The Friday night party was fun, with the Captain making an appearance.

    Photo Mar 06, 2 43 03 PM

    All in all a great trip.

    Now back to work.

  • Allowing a User to Create Objects in a Schema

    I was testing something the other day and realized this was a security area I didn’t completely understand. I decided to write a few posts to help me understand the issues.

    I want to give a developer rights to create objects in a schema. In this case, I’ll stick with procedures, but the same thing would apply for tables, views, etc. How do I do this, allow someone to create objects in their schema?

    Let’s create a login and user:

    CREATE LOGIN steve WITH PASSWORD = ‘AR3allyStr0ng!P@**Wo9d’;
    GO
    USE Sandbox
    GO
    CREATE USER Steve FOR LOGIN Steve
    GO

    Now I have a user, and want them to be able to create this:

    SETUSER ‘Steve’;

    CREATE PROCEDURE Steve.MyProc
    AS
        SELECT
                1;
    RETURN

    If the user does this, they get:

    Msg 262, Level 14, State 18, Procedure MyProc, Line 3
    CREATE PROCEDURE permission denied in database ‘sandbox’.

    That’s no good.

    We can see from the error that we don’t have writes to create procedures. Let’s fix that. First, we change our context and then we grant permissions.

    SETUSER
    GO

    GRANT CREATE PROCEDURE TO Steve;

    GO

    With this done, let’s now try creating the procedure again with the SETUSER statement and the CREATE PROC statement. We then get:

    Msg 2760, Level 16, State 1, Procedure MyProc, Line 5
    The specified schema name "Steve" either does not exist or you do not have permission to use it.

    This didn’t used to be the case in SQL 2000, where schemas didn’t exist. Now we don’t have any implicit schema for our user. Let’s see if we can make anything.

    CREATE PROCEDURE MyProc
    AS
    SELECT 1;
    RETURN
    GO

    Returns this:

    Msg 2760, Level 16, State 1, Procedure MyProc, Line 11
    The specified schema name "dbo" either does not exist or you do not have permission to use it.

    At this point Steve doesn’t have permissions to any schema. Let’s start by adding a new schema.

    CREATE SCHEMA Steve
    GO

    Once this is done, can I now create a procedure?

    SETUSER ‘Steve’;

    CREATE PROCEDURE Steve.MyProc
    AS
        SELECT
                1;
    RETURN

    I get this:

    Msg 2760, Level 16, State 1, Procedure MyProc, Line 5
    The specified schema name "Steve" either does not exist or you do not have permission to use it.

    The same error as before. This makes perfect sense because although the schema exists, I don’t have permissions to use it.

    That’s the default in SQL Server. You don’t get any permissions by default. You need to explicitly set them.

    In this case, I want Steve to have control of the schema [Steve], so I really want the user, Steve, to own it. How do I do this?

    The key is that I want to use the Authorization clause with CREATE SCHEMA. I can’t use this with ALTER SCHEMA, only with CREATE SCHEMA.. so I need to do this:

    SETUSER
    GO
    DROP SCHEMA Steve;
    GO
    CREATE SCHEMA Steve AUTHORIZATION Steve;
    GO

    Once this is done, I can now let my user create procedures.

    SETUSER ‘Steve’
    GO
    CREATE PROCEDURE Steve.MyProc
    AS
    SELECT 1;
    RETURN
    GO

    This works, and my developer can work in their own schema. Of course I need to ensure the developer has access to other objects, hopefully using a role of some sort that I’ve created for my application users.

     

    SELECT SUSER_NAME();

    DROP SCHEMA Bob
    DROP SCHEMA steve

    REVOKE CREATE SCHEMA FROM Steve

    CREATE SCHEMA Steve AUTHORIZATION Steve

    ALTER SCHEMA Steve AUTHORIZATION Steve

    SETUSER ‘Steve’;
    SELECT SUSER_NAME();

    CREATE PROCEDURE Steve.MyProc
    AS
        SELECT
                1;
    RETURN

    CREATE PROCEDURE MyProc2
    AS
        SELECT
                1;
    RETURN

    SETUSER;
    SELECT SUSER_NAME();

    GRANT CREATE PROCEDURE TO Steve

    SETUSER
    DROP PROC steve.MyProc;
    DROP PROC steve.MyProc2;
    DROP SCHEMA Steve;

  • Altering a Column with NOT NULL

    A short piece, as I ran into the need recently to alter a column to NOT NULL status. I’ve rarely done this in the past, usually specifying NOT NULL when I create the table. Often in future changes, I’ve been wary of not allowing NULLs since I’ll always find an application, or worse, a business situation where there is no good value available. However that’s a separate discussion.

    Altering the Column

    Let’s say I have a column that is specified as NULL in a table, and I want to change that. I initially tried this:

    ALTER TABLE Tags ALTER COLUMN Status NOT NULL;

    However, I got a syntax error. For the life of me, I couldn’t understand why, so I looked up the syntax. If you look at the ALTER TABLE syntax, it shows that the ALTER COLUMN item needs the type included. While I am not changing the data type, to alter the column, I need to do:

    ALTER TABLE Tags ALTER COLUMN Status tinyint NOT NULL;

    Another inconsistency in SQL. We don’t provide the whole definition again, and here we need to provide the column definition, even when only changing one of the settings.

  • Learning Continuous Integration for Databases – LA Apr 10

    I’ve been talking about continuous integration for databases for a couple years now as a part of my job. My employer, Red Gate Software, has been building tools to help database developers build better software. We (Red Gate) want to sell software, but we also really want to help people build better software. It’s a big reason why I’m employed there. Red Gate truly wants to make the world a better place while we run a business.

    I’ve gotten lots of interest and questions from my one hour talk and late last year Red Gate decided we needed to do more. We built some all day continuous delivery classes last year and they went over well. Over the winter, Grant, myself, and a few others at Red Gate got together and we’ve been working on adding depth to our instruction and have come up with 3 full days of training to help you build better database software, quicker.

    Continuous Integration in LA

    The middle class we’ve developed is an all day look at how you implement a continuous integration process with a database and application. On April 10, 2015, I’ll be coming to Los Angeles, CA, along with one of our partners, Ike Ellis, to work on a full day of training. It’s a $500 class, but you’ll walk through a couple of different ways to set up a CI process, actually perform the steps yourself, and make changes to the database that get built and tested.

    We think it’s a great way to smooth out your development process and bring more engineering to the way you deploy database updates. Ike is an expert SQL Server consultant and he’ll show you how to create your own CI process. I’ll be in the background to help out, and we think you’ll gain some in depth knowledge that you can use at your job right away.

    If you want to advance your database development, register today and join us in LA on April 10, 2015.

    register

    I’m excited to be a part of these classes, and I hope you are as well.

    We do cover a number of Red Gate tools in the classes, but the procedures and steps are applicable to other methods of accomplishing the same tasks. Even if you choose to use other tools, or write your own, the skills we teach you will be applicable.

    I wouldn’t write my own, however. I’d easily burn the cost of the tools many times over trying to iron out the bugs in my own process.

    The Continuous Delivery Process

    The whole idea of continuous delivery is that you can make changes at anytime. It isn’t sloppy work, untested development, or anything else. This is a way to bring more engineering to software development, and I really believe in it.

    It’s not easy, however, and that’s why we’ve built three days of training. We cover these items in the three days.

    • Day 1 – Version Control for Databases
    • Day 2 – Continuous Integration for Databases
    • Day 3 – Automated Deployment

    We haven’t set these up all in one week, mainly because it’s too much information for you at once. Ideally we want to tour around, running one of these classes each quarter, because it will take you a few months to implement the information and understand it.

    If you get past these courses, we’re also partnering with expert ALM consultancy shops that can help you even more.

    We’ve got a number of all day events coming up for you to consider, so check out our list of training days. We’re adding more all the time, and let us know if you want us to come to your area.