Author: way0utwest

  • Duplicate Identity Values?

    Can you have duplicate values in a field with the identity property? Of course, and this does it.

    DROP TABLE dbo.MyTable
    
    CREATE TABLE mytable
    ( id INT IDENTITY(1,1)
    , mychar VARCHAR(10)
    )
    GO
    INSERT mytable SELECT 'A'
    INSERT mytable SELECT 'B'
    INSERT mytable SELECT 'C'
    
    
    SELECT * FROM dbo.MyTable

    This returns these values:

    result1

    Then we use Identity_insert

    SET IDENTITY_INSERT dbo.MyTable ON
    GO
    INSERT dbo.MyTable
            ( ID, myChar )
    VALUES  ( 8, -- myID - int
              'H'  -- myChar - varchar(20)
              )
    SET IDENTITY_INSERT dbo.MyTable OFF
    
    SELECT * FROM dbo.MyTable

    result2

    Now we reseed and add more values

    DBCC CHECKIDENT('mytable', RESEED, 4)
    
    INSERT mytable SELECT 'E'
    INSERT mytable SELECT 'F'
    INSERT mytable SELECT 'G'
    INSERT mytable SELECT 'H'
    INSERT mytable SELECT 'I'
    
    SELECT * FROM dbo.MyTable

    result3

     

    You can see that we have two ID rows with “8” in them. Clearly a duplicate.

    Identity doesn’t guarantee uniqueness. If you want that, make a PK or add a unique index.

  • The Care of Data

    It's not just a Dropbox problem

    DBAs are supposed to be trustworthy. After all, they are the custodians of data and often have access to sensitive information because of the nature of their system administrator level privileges. Their turnover ought to be low, and hopefully they have spent years building skills and a reputation that will provide them with a good job. They ought to value this investment and treat it seriously. Customer Service people are not usually in the same position in their careers, often at the beginning of their technical careers and usually change jobs regularly.

    Recently Dropbox had to back off the stance that it’s employees can’t view your data, with this note that their staff can access your files in some circumstances. There’s no evidence that employees have mis-used their access, but it could happen, and that’s a concern. It’s a concern with any cloud based service, and I think this is one area that cloud-type vendors really need to assure their customers that it won’t happen.

    Another major concern is overall security. If a cloud vendor’s employees can access your files, so can a hacker that gains access. That is, likely, an overriding concern of many customers, and it’s an area that I think that we really need to disclose openly the measures taken, the auditing in place, and the monitoring to detect any issues. Better encryption that actually prevents access by the vendor or it’s employees is a better solution.

    I hope we get encryption methods because the third major concern with cloud data is access by legal authorities. There are cases where the government might have a right to access your data, but that should be when they serve you with notice, not some company that is holding your data.

    There are many great customer service people and DBAs with strong worth ethics and morals. They take their responsibility as the custodian of your data seriously. There are a few, however, that are not so professional, and release information, sell data, put stories or video on some site like YouTube or TheDailyWTF for a laugh. Something that I’m not sure most of us that store data in the cloud would like to see happen with our pictures or video, and definitely something that companies would not want to see with proprietary information.

    Steve Jones


    The Voice of the DBA Podcasts

  • Identity Reseeding

    I love the identity property. I use it in many of my tables, mostly because it gives me a fairly reliable surrogate key that I can use in my tables, especially when testing something. I often do something like this:

    CREATE TABLE MyIdentityTest
    ( id INT IDENTITY(1,1)
    , mychar VARCHAR(10)
    )
    GO
    INSERT MyIdentityTest SELECT 'A'
    INSERT MyIdentityTest SELECT 'B'
    INSERT MyIdentityTest SELECT 'C'
    GO

    In this table, I have these results:

    id          mychar

    ———– ———-

    1           A

    2           B

    3           C

    If I then look to reseed things for some reason, maybe I want to leave a gap somewhere, I can do this:

    SET IDENTITY_INSERT MyIdentityTest ON
    INSERT MyIdentityTest (id, mychar) SELECT 12, 'L'
    GO
    SET IDENTITY_INSERT MyIdentityTest OFF
    GO

    This means my table now looks like this.

    id          mychar

    ———– ———-

    1           A

    2           B

    3           C

    12          L

    If I insert a new value:

    INSERT MyIdentityTest SELECT 'M'
    GO
    

    And now check all the results, I have this:

    SELECT * FROM myidentitytest

    we get

    id          mychar

    ———– ———-

    1           A

    2           B

    3           C

    12          L

    13          M

     

    Suppose I realized that I had a problem and decided to “fix” my identity values. I can reseed like this, which sets the identity property tracker back to 3.

    DBCC CHECKIDENT(myidentitytest, RESEED, 3)
    go
    INSERT MyIdentityTest SELECT 'D'
    GO

    However look at the results of the insert. It shows 4 instead of 3, which is what I want in this case.

    SELECT * FROM myidentitytest

    id    mychar

    —– ———-

    1     A

    2     B

    3     C

    12    L

    13    M

    4     D

    Quite a few people think that if I set the identity to “3”, I should have 3 as the next value. That’s not the case, and it’s something to be aware of when working with identities. If you are looking to fill gaps or move your seed for some reason (like merge replication), understand that you are inserting the “last” value as your seed, not the “next” one.

  • The Ad Hoc Change

    Ad Hoc changes are not what I like to makeHow many times have you been asked to change data in a production system? If your career has been like mine, it’s probably too many times to count. It seems that there are always data issues in production, and the DBA is asked to fix or correct something. In my mind, there are two many causes of this: user error and code bugs.

    In both cases, you would hope that some application contains the feature to allow a user to fix an error: either one they created or one the application slipped in. However in the reality of today’s IT world, too often there are not enough tools to allow an application to be used to correct issues. Just like testing, it seems that too often we haven’t spent enough resources before deployment in an area where they are needed: tools. As a result, it’s time for the DBA to change things.

    I saw a blog from Jon Russell recently that pointed out a few things that it’s easy to forget when making these changes. Many DBAs know their systems very well, understand the data relationships between tables, and hopefully, have declarative referential integrity (DRI) in place to ensure data integrity. However it’s easy to forget about some business rule coded in a trigger, or the downstream implications of a data change. That’s was a problem at SQLServerCentral at one point when I corrected someone’s question of the day response, but didn’t realize that their total points are stored elsewhere and needed to be updated separately. In that case I ended up with a lot of data to fix.

    We do have to make manual changes to data at times. When we do, Jon’s list of steps to include in the process is important, especially in many companies where auditing is demanded or even required. Keep copies of the old data, document what you did, and most importantly, make sure you’ve sent notifications. Often if an error crops up, it will be noticed by the end-users that usually work with the data. An email from the DBA just might help them find mistakes quicker, and prevent even more problems.

    Steve Jones


    The Voice of the DBA Podcasts