Author: way0utwest

  • The Worst Comments

    I was watching a presentation recently on refactoring C# code and was amazed by some of the comments that the speakers showed in the code. The example was a real application that had been obfuscated and simplified a bit for the talk. The comments, however, had only been changed when they might disclose a specific person or company. The speakers pointed out a few of those changes, but also noted that most of the comments were verbatim from the original code.

    Comments like “Dave changed this from the old way”  or “Bug 445: as per the operations group” were good examples of bad comments. These items don’t really help a developer understand the code. The comments in application code should be there to add to the code itself, helping someone understand a reason for the code, not an obscure reference or an obvious statement (“this code adds two balances together).

    With that in mind, I’m sure many of you have come across some comments in code that have evoked a wide range of emotions. I’m sure you’ve been frustrated, annoyed, or something else. Perhaps even from your own comments. With that in mind…

    What are the worst comments you have found in code?

    I hope you don’t have examples in your current application, but perhaps you do. Perhaps you have even committed your own code recently without really taking the time to accurately describe the change. Maybe you want to go look in your VCS and see what you’ve entered lately.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • 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.