Temp Tables revisited

  • Sergiy

    SSC Guru

    Points: 109851

    Comments posted to this topic are about the item Temp Tables revisited

  • vinu512

    SSCoach

    Points: 15729

    Good question on how parsing works.....very important to know the internals well.

    Vinu Vijayan

    For better and faster solutions please check..."How to post data/code on a forum to get the best help" - Jeff Moden[/url] 😉

  • Vinay Kumar

    SSCertifiable

    Points: 6098

    Good basic question. But unfortunately, i have selected wrong one in hurry :pinch:

    Thanks
    Vinay Kumar
    -----------------------------------------------------------------
    Keep Learning - Keep Growing !!!

  • kapil_kk

    SSC-Insane

    Points: 21316

    Danny Ocean (6/23/2013)


    Good basic question. But unfortunately, i have selected wrong one in hurry :pinch:

    +1

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • sharath.chalamgari

    SSCertifiable

    Points: 5680

    what could be the better approach in this kind of situation , is there any better option than this

    DECLARE @MoreColumns bit;

    SET @MoreColumns = 1

    Create table #table( id int )

    IF @MoreColumns = 1

    alter table #table

    add col1 varchar(10)

    ELSE

    alter table #table

    add col2 varchar(10)

    DROP TABLE #Table

  • sharath.chalamgari

    SSCertifiable

    Points: 5680

  • Christian Buettner-167247

    SSChampion

    Points: 13729

    Why was this question reposted with the same misleading explanation as the original QOTD a month ago?

    Best Regards,

    Chris Büttner

  • Lokesh Vij

    SSChampion

    Points: 10836

    sharath.chalamgari (6/24/2013)


    http://support.microsoft.com/kb/295305

    I never thought about creating a temp table using if/else statements. Seems this is a good way. Thanks for sharing 🙂

    If that was not a temp table, we can use EXEC ('CREATE TABLE <>....') as well.

    ~ Lokesh Vij


    Guidelines for quicker answers on T-SQL question[/url]
    Guidelines for answers on Performance questions

    Link to my Blog Post --> www.SQLPathy.com[/url]

    Follow me @Twitter

  • Hugo Kornelis

    SSC Guru

    Points: 64685

    Good question, and mostly correct explanation. Except for the last sentence.

    Such an error breaks the integrity of the code and makes further evaluation impossible. Parsing stops immediately at this point and the DROP statement is never evaluated.

    This is not true. Parsing does continue. The reason the DROP TABLE does not generate an error is because of "defered name resolution" - if a table does not exist at parse time, it is still accepted and SQL Server will continue parsing and compiling the batch, making a mental note to retry parsing and compiling the offending statement at execution time. This is in order to support scenario's where a table is created while the code is running (e.g. a permanent table created by a called stored procedure, or by <shudder> dynamic SQL).

    One way to check this is to change DROP TABLE to DROP TALE - you will now get a third error message, that TALE is not a supported object type for CREATE, DROP, or ALTER. Another way to see this in action is to execute this batch:

    SELECT 1;

    DROP TABLE #TableA;

    If you run this, you'll get a result set with "1", and an error message - this indicates that the error was only returned after the initial parse and compile; executing the first select; and then the second attempt to parse and compile the DROP statement. Conversely, the batch below will ONLY return an error message, indicating that even the first statement of the batch was not executed because the error was generated during the initial parse and compile:

    SELECT 1;

    IF 1 = 1

    CREATE TABLE #Table (A int);

    ELSE

    CREATE TABLE #Table (B int);


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Hugo Kornelis

    SSC Guru

    Points: 64685

    sharath.chalamgari (6/24/2013)


    what could be the better approach in this kind of situation , is there any better option than this

    Rethink your design.

    Seriously. SQL is not designed for tables that can contain just about everything. If you start your process with a solid data model, you'll get a solid database design. In that design, each table has a fixed set of columns that will not change at run-time. So in a well designed database, you should not need this kind of nonsense.

    The only situations where I have seen this kind of code are:

    1. No solid design, or a "design" (and I'm using that word in a very loose sense) that allows end users to add columns at run time. That's not what the relational model is for. Use relational tables for structured data, and if the user has a need for additional unstructrured data, provide them with an XML column for that. There may be other alternatives, to be decided on a case by case basis, but the bottom line is that "normal" tables should be fixed and only change during deployment, and flexible schema should be in its own separate area.

    2. Generic purpose stored procedures that do "something" for generic tables. Just don't. How hard can it be to make multiple copies of the stored procedure and adapt them as needed to the specifics of each table? I much rather have twenty-five almost identical stored procedures that are elementary to graps and simple to maintain, than one "generic" stored proc that needs so much control flow to handle all special cases that it will become a maintenance nightmare the minute the original developer moves on.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Hugo Kornelis

    SSC Guru

    Points: 64685

    Christian Buettner-167247 (6/24/2013)


    Why was this question reposted with the same misleading explanation as the original QOTD a month ago?

    If you are refering to the mistake in the last sentence (that I commented on in a previous post), then I think "misleading" is a bit harsh.

    If you are refering to something else, I must have overlooked it. And I don't have the time to go back over the QotDs of the last weeks, so maybe you can help me refresh my memory?


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Christian Buettner-167247

    SSChampion

    Points: 13729

    Hugo Kornelis (6/24/2013)


    Christian Buettner-167247 (6/24/2013)


    Why was this question reposted with the same misleading explanation as the original QOTD a month ago?

    If you are refering to the mistake in the last sentence (that I commented on in a previous post), then I think "misleading" is a bit harsh.

    If you are refering to something else, I must have overlooked it. And I don't have the time to go back over the QotDs of the last weeks, so maybe you can help me refresh my memory?

    To make the story short: You cannot create a temporary table more than once in the same batch. It doesnt matter if you have control flow logic or not.

    CREATE TABLE #Test (a INT)

    DROP TABLE #Test

    CREATE TABLE #Test (a INT)

    DROP TABLE #Test

    GO

    You will get the same error that the table already exists.

    More important - if you use regular tables instead, the query works just fine.

    Best Regards,

    Chris Büttner

  • call.copse

    SSCoach

    Points: 17241

    sharath.chalamgari (6/24/2013)


    what could be the better approach in this kind of situation , is there any better option than this

    ...

    Personally I'd suggest that if you are creating two temp tables with different structures they are serving different purposes. So name them differently according to their purposes e.g. CREATE TABLE #FullDesc and CREATE TABLE #ShortDesc in the case of the original question. It's not like you could query the two tables interchangeably. Suitable modifications to the subsequent control structure would depend on what you are doing.

  • Hugo Kornelis

    SSC Guru

    Points: 64685

    Christian Buettner-167247 (6/24/2013)


    More important - if you use regular tables instead, the query works just fine.

    Hmmm, that's a surprise to me! I thought you'd get the same problem when using permanent tables. So there is, apparently, much more to this than I first though.

    Thanks for putting me straight! 😉


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • PurpleLady

    SSCertifiable

    Points: 7647

    Definitely have to slow down and read ALL the answers:)

Viewing 15 posts - 1 through 15 (of 26 total)

You must be logged in to reply to this topic. Login to reply