I guess my take on such a thing (and it IS just an opinion, not an argument) is that if someone is passing "at least hundreds" in such a list, there's a pretty strong chance that someone might have a problem with their design.
I went through such a thing two years ago with a company that really didn't know how to use T-SQL. They would take 4 inputs from the user and then generate a couple thosand rows of data to be inserted into a table. The problem was that they were generating those rows on the application side of the house and then trying to pass them to SQL Server. They first tried passing the information as individual INSERT/VALUES statements. You can just imagine how badly that choked. They then tried passing them as one big ol' delimited string and parsing them on the server side. While that certainly worked better, it still choked the pipe between the sender and the server.
I showed them how to pass the 4 parameters that defined the data they wanted to build and then how to build that data on the server side. The whole process dropped from a 40 minute, pipe choking, server clogging, resource monging process to a server side run of about 3 seconds.
Heh... I told you that story so I could tell you this one. :-) Because of my extreme bias in passing such large amounts of data to a stored proc (even inside the server), I'd be ill suited to write such a thing. I will, however, be happy to tech review such an article if someone wanted to take it on.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs