Best options for this scenarion

  • Hi,

    I have two dynamic pivot tables that I need to join. The problem I'm running into is that at execution, one is ~7500 characters and the other is ~7000 characters.

    I can't set them both up as CTEs and query, the statement gets truncated.

    I can't use a temp table because those get dropped when the query finishes.

    I can't use a real table because the insert statement gets truncated.

    Do I have any other good options, or am I in Spacklesville[/url]?

    For reference, this is what I'm doing.

    Thanks!

  • I'm not sure I understand the problem. The allowed @SQL string is NVARCHAR(MAX) (as you defined in the post you linked to). So why would 7000+7500 characters be too much for it?

    Granted it won't display the entire thing if you try to PRINT it, but that won't stop it executing.


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • Hi Dwain,

    In my tinkering with it, it certainly seemed like the error messages I'd get would match where the print statements stopped printing.

    So, if the error was something like "incorrect syntax near FROM", the print statement would cut short some of the table name.

    I'm currently using varchar(max) so it does print as much as possible for debugging. I'll try nvarchar(max) out and see if it executes.

    All this EAV nonsense is making me want to learn Java or something. Sheesh. :angry:

    Thanks!

  • Maybe you need to take a look at this (by Jeff Moden):

    Display More Than 8000 Characters [/url]


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • I also did something interesting in this article, where I used DelimitedSplit8K to format a dynamic SQL string into lines, butit only works with strings that are up to 8000 in length. However if you had a splitter that operated on NVARCHAR(MAX) you could use the same technique, the benefit of which is that it displays line numbers along with the Dynamic SQL that conform to the error messages.

    How to Design, Build and Test a Dynamic Search Stored Procedure [/url]


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • That was the link in my Spacklesville comment in my first post 🙂

  • erikd (12/11/2013)


    That was the link in my Spacklesville comment in my first post 🙂

    Ah! So it was! Sounds like your community. 😛


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • Yessir. Spacklesville. Population: me.

    Maybe I'll take up whittling.

Viewing 8 posts - 1 through 7 (of 7 total)

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