identifying many to many relationship between columns

  • I wish I had even a fraction of the clarity you have for these things.


    "If I had been drinking out of that toilet, I might have been killed." -Ace Ventura

  • Dwain,

    I did remember to cast to varchar but may not have matched the actual length of varchar in the table. Can you tell me why this exact match would be important?

    Thanks again for all your work. I won't get back to this until the AM in the US

  • lmeinke (11/13/2013)


    Dwain,

    I did remember to cast to varchar but may not have matched the actual length of varchar in the table. Can you tell me why this exact match would be important?

    Thanks again for all your work. I won't get back to this until the AM in the US

    I think the error message kind of tells you. Each column returned by the anchor and recursive legs of the rCTE must match in data type and length.


    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

  • Dwain,

    The error message only mentions a type mismatch...nothing about length. I will continue to work on this this morning as time permit.

    Again, thank you very much for your tenacity and I hope we can make this more efficient.

    Lonnie

  • OK...my issue again....sloppy typing. I had an nvarchar type vs. varchar type...sorry.

    Dwain's solution does run however it returns double the number of rows from my original table and takes 36:37 to run vs. 8 minutes. Not sure what the difficulty is here as Dwain's solution is not cursor like and I would have expected much better run times.

    Thank you again to Dwain.

  • Gosh! That bad, huh? Guess you can't win them all.


    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

Viewing 6 posts - 16 through 20 (of 20 total)

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