Inserts

  • Nice trick. I looked at the last number as 1000, but didn't take into account the first value was 0. At least I learned something new today, and while I've used those expressions from time to time, I'd never think of using that many! 😛

  • Ugh, I overlooked the 0 value as well.

    Maybe I should wait to answer these questions in the afternoon. :doze:

    Good question though.

  • Good Question!

    Best,
    Naseer Ahmad
    SQL Server DBA

  • Didn't know about the 1000 value limit, but did correctly discern the question was about that limit. As I never use that many explicit values (usually paste them into a "temporary" permanent table - I have a few set up for just such an occasion - use the values & clear the table), I had to guess, and guessed wrong.

    Thanks to OP for question. Good lesson to pick up.

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • Nice Question

  • I got this correct for all the wrong reasons. I didn't have a clue what the point of the question was but since the variable, temp table, and persistent table were not defined I assumed they would all fail. I was actually thinking I would have gotten the wrong answer and was prepared to argue my case.

    I have never run up against the max row values because I would have not used that syntax to get anywhere near 1,000 rows.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • sknox (8/23/2012)


    For once I am going to say that the table declarations were best left out -- they would not have helped, and just might have muddied the waters.

    I disagree,

    I got this question right because they weren't there.... I wondered if it was testing me to see if I would catch that.

    After all

    SELECT

    blah

    INTO #temp

    works.... somebody might have thought INSERT INTO #Blah without defining #Blah would also work.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • Starting with 0, not 1, is totally fair and not "tricky." This is something for which IT professionals should be on the alert every waking minute (even prior to that first or second cup of coffee!)

  • SQL Kiwi (8/23/2012)


    I also knew the fact the question was looking to test, but fell foul of the start at zero like so many others.

    I personally think the question would have been improved by omitting the trick.

    Perhaps, but I suspect you and many others will remember this bit of trivia better because of the trick.

  • mtassin (8/23/2012)


    sknox (8/23/2012)


    For once I am going to say that the table declarations were best left out -- they would not have helped, and just might have muddied the waters.

    I disagree,

    I got this question right because they weren't there.... I wondered if it was testing me to see if I would catch that.

    After all

    SELECT

    blah

    INTO #temp

    works.... somebody might have thought INSERT INTO #Blah without defining #Blah would also work.

    I'll disagree with you and agree with sknox.

    If you thought that you could do an insert into @x without defining @x, you would learn something here as well.

  • Steve Jones - SSC Editor (8/23/2012)


    I'll disagree with you and agree with sknox.

    If you thought that you could do an insert into @x without defining @x, you would learn something here as well.

    Granted, but if the intent was to teach me about the limitations of the maximum number of values that you can pass to insert, it missed that point because I thought it was talking about needing to declare variables.

    A lesson taught, true, but when I looked at the question, I didn't even look closely at the values being inserted to catch that because the absence of the table declarations meant Errors to me.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • anthony.green (8/23/2012)


    More coffee needed, I didn't read the question right, thought it was inserting many columns not 1 column, so the limit would of been 4096 so selected S,E,E doh to early on this grimm Thursday morning.

    Sure

    Happy

    It's

    Thursday!

  • Steve Jones - SSC Editor (8/23/2012)


    I'll disagree with you and agree with sknox.

    If you thought that you could do an insert into @x without defining @x, you would learn something here as well.

    +1 from me. Since the question specifically mentioned an error message on exceeding the maximum number of values, it was completely obvious that prior existence of the tables, with the appropriate definition, should be assumed.


    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/

  • Why is everyone calling it a trick question? It started with (0), it is a valid value.

  • mtassin (8/23/2012)


    sknox (8/23/2012)


    For once I am going to say that the table declarations were best left out -- they would not have helped, and just might have muddied the waters.

    I disagree,

    I got this question right because they weren't there.... I wondered if it was testing me to see if I would catch that.

    The question included a very specific error message as your only failure option, which was clearly not related to the (non)existence of a table. You happened to get it right because you didn't read that error message carefully. There are always going to be those who don't read the question carefully. Some will get credit they don't deserve, and some will not get credit they should have. That does not reflect on the quality of the question, in my book.

    This question provided all of the information necessary for someone who knew the subject being tested to be able to answer it correctly. The answer provided a good explanation and valid references. That, to me, is the hallmark of a good question.

Viewing 15 posts - 31 through 45 (of 62 total)

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