Results 1 to 12 of 12
  1. #1
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6

    Unanswered: PKs, temp tables, what?

    This is not my code.

    So if my primary key clustered index is on MyThings.MyThingsID, how does the INSERT INTO the temp table #MyThingsWithFilter ever return a PK violation on the PK on the temp table.

    I do not get it. It is not a feak error either. A few hundred times today.

    IT WILL NOT LET ME POST MY CODE. FAIL.

    So this is what is happening.
    1. Inside a stored proc
    2. I have temp table with a PK on one column on the surrogate key.
    3. The temp table is checked to exists, dropped and recreated. The PK is not explicitly named.
    4. I am selecting from a real table with NO JOINS and even a questionable DISTINCT clause where this same field is the PK. There are no dupes, nor should there be.
    5. How am I getting hundreds of PK violations in production today from this proc and temp table?

    Wierd.
    Last edited by Thrasymachus; 02-14-12 at 15:04.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  2. #2
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    Is the temp table explicitly dropped at the end of the procedure? I have seen temp table creation fail, if the procedure is called very rapidly, and the temp table is not explicitly dropped.

    After that, I would suspect the joins. I expect you have already created the table without the PK, and checked for duplicates.

  3. #3
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    The INSERT INTO on the temp table can fail if there are PK duplicates in the incoming data stream or if you attempt to insert a value into the temp table that a previous step had left in the temp table.

    If VBulletin is being persnickity about posting your code, email it to me and I'll post it for you.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  4. #4
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    No dupes. No joins. One table. DISTINCT even. I figured it out I think. NOLOCK hint is my working theory. INDEX page encountered when the thing is in one status, the ID is added to the table, the transaction complete or whatever and the second index page is encountered because the thing is in another status.

    I am not going to take the NOLOCK off because it will cause blocking if this damn thing is really that busy. I am just going to drop the PK part of the clustered index and handle any dupes in the code.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  5. #5
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Can't you post any code?
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  6. #6
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    I tried. Kept getting FAIL.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  7. #7
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    I think I figured it out anywho. I know it sounds like I am stretching, but it is the only possible explanation.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  8. #8
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    was to code to HUGE?

    What's do you THINK the problem is?

    Give..give...

    PEBKAC?
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  9. #9
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    I do not know why DBForums would not let me put code. I think I am having dirty read problems here at the shop.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  10. #10
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    No, I meant what do you discover about your temp table problem?

    I might suggest a permanent table with a column of SPID for each process instead of a temp table
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  11. #11
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    I think it was an isolation level issue\dirty read issue. It is the only explanation I have for a single insert from a single table (no joins) and a DISTINCT into a temp table with the same primary key would throw a PK vioation on the temp table. I do not think it is because the temp table is still somehow not dropped from the last execution because there is an OBJECT_ID check with a DROP statement. The WHERE clause had 2 statuses in it. One "ready for processing" and the other "processing". The process that moves from the one to the other must have been firing when this other proc was firing. Thus picking up the record twice because of the NOLOCKs. It is the only plausible scenario I can see.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  12. #12
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    way to go M$...nolock

    how often is that "hint" over/misused?
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •