The problem with it (that I thought was overkill) was that in that example you need to have a function for the splitter. Not everyone has that installed on their systems (myself included). For everything I use SQL for at my workplace, we do not have a real-world use for a string splitter to be stored in SQL. Splitting strings doesn't feel like a SQL task, but more of an application task (most .NET languages for example do string splitting quite well). So building a function to split the string (yes, I know it has been done on the forum and optimized to death) still feels like overkill to me.
But now I feel like I am getting off topic.
I Definitely wouldn't suggest that splitting strings is an application task. Consider that in SSRS if you're passing multi valued parameters, that they are provided in a delimited string. If you didn't split those in SQL, how would you use it? Just an example. 🙂
SSRS can actually do this for you, but you'll have to use an "in" expresison in your "where" clause and then SSRS will hardwire the comma'd parameters before sending the entire mess to SQL. You CAN use the splitter server side tho, so you have your choice. I found this out by tracing a report one of my compadres did and thats what happened, SSRS built a list of all the multivalued selections and sent the entire hardwired list to the server.
What I did was instead send the list to the server instead and split it there, but I did it on the fly without the delimiter8k function, I just included code in the sql that was called to split the list. I couldn't use the delimit8k at the time but nothing stops you from doing similar code inline without the function right?