>Thank you for your reply. I wish I knew about this feature before. My ASP.NET application needs to pass a table to a stored procedure. So, I was serializing the table into an XML string and passing it. Very long and kludgy procedure. Now I am thinking if I should change the approach. Any time I change one thing, I brake something else :) Plus, the time of refactoring this code could be spend on something more productive :)

My 2 cents, Microsoft was very late in implementing that feature. I realize 2008 seems like a lifetime ago, but they should have implemented it in 2005, when Visual Studio .NET had already gone through multiple iterations.

And even then, it doesn't work with other products. You would "think" that SSRS would allow you to pass a data table as a parameter to a stored proc - it doesn't. (Though some people have come up with some workable, though complicated, workarounds)

So as a result, MANY developers came up with variations of the process of converting a table to XML (or a comma separated list). Sure, it "works", though the data table approach is cleaner - only problem, by they time they released it, so many had already invested in a solution that changing the code base wasn't always worth it.

These days I try to show younger SQL developers how to use it to avoid using a cursor (row-by-row approach)

So if what you have "works", I'd say keep it. But for any new development, if you can use it, it's worth doing so.

Sorry for the long-winded answer, but this is one of the many reasons I'm glad I'm out of the MVP program and that entire area - I can speak more freely. :)