• Naive, eh Eirikur? Hehe. I like that.

    As I said it's been awhile since I was playing around with functional encapsulation of this process, and because of the elapsed time that has passed I'd forgotten why I ultimately abandoned it. The fastest (highest performance) approach is going to be to use dynamic SQL to create and execute a code string that will look something like this (if you will pardon the fact that I'm about to fall asleep and haven't tested it).

    UPDATE dbo.Questions

    -- As many REPLACEs as there are rows in Alan.B's strings table

    SET Question = REPLACE(REPLACE(REPLACE(Question COLLATE Latin1_General_BIN, bs1, gs1), bs2, gs2), bs3, gs3);

    Where bs1, bs2, bs3 are the bad strings and gs1, gs2, gs3 are the good ones.

    Edit: Note that it will make building the dynamic SQL easier if you put the CHAR offsets (integers) into the character substitution table instead of the strings themselves, so you don't have to worry about the correct number of quotation marks.

    You can also do it with a recursive CTE. This actually doesn't perform too badly on small sets of questions and character substitutions, but it generates a whole lot of rows you end up throwing away if you have many subsitutions.


    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