Depending on how you use XML as was previously mentioned can cause an issue with the special XML characters. You would probably want to do an initial select to get it encoded properly possibly nesting it inside your code. Here is an example showing the characters getting entity encoded.:

For all interested in performance aspect, XML data types are powerful but expensive. For XML queries, execution plan means very little. As the XML payload/ nodes increase or node iteration increases, LOB parsing becomes extremely heavy. Processing raw XML without indexes or schema applied on it, is similar to a heap in concept but worse because XML parsing adds a heavy layer. Schema helps with the read-aheads and Iops. Adding indexes helps with the lookup. Caveat with the indexes, needs sufficient head room for growth. Some of the benchmarks from my a prior project, the index size is roughly 10-12 times the data size for a 500+ node XML. Here is a sample benchmark, 200 node XML of roughly 69K size has a 810K index size. The size of the data matters as well.

Without taking away the spotlight from Divya's cool technique, if there are numerous XML nodes I would 1. pin the XML data to physical table and column2. create a schema and apply it on the XML column3. make the table transient to save on disk space. This means maintenance to defrag4. apply primary and at least secondary PATH index5. maintain a seperate LUN for the table, if using the second example to split numerous rows in the table

I'd seen XML string splitting and concatenation before, but ran into issues with characters that aren't valid in XML. I found that just escaping all the invalid characters prior to splitting frequently took more time than the entire split operation using a tally table.

That said, if you can qualify your data enough to ensure you won't ever have those sorts of issues, then it is certainly easier to code than some other solutions.

This is the table to run the function against, with a few sample record results. Select versions from versiontable13.0,13.1,14.0,14.113.0,13.1,14.0,14.113.0,13.1,14.0,14.113.0,13.1,14.0,14.111.0,11.1,12.0,12.1,13.0,13.1,14.0

I tried this. Now it no longer recognises the function. Is the syntax wrong?select fn_Split(versions, ',') as SingleVersion from versiontable where versions is not nullServer: Msg 195, Level 15, State 10, Line 1'fn_Split' is not a recognized function name.

Tried this also.select dbo.fn_Split(versions, ',') as Version from versiontable where versions is not nullServer: Msg 208, Level 16, State 1, Line 1Invalid object name 'dbo.fn_Split'.

Any suggestions to get the query to work or even better, a nifty method to accomplish this within my data flow task using one of the Data Flow Transformation. Seems like the pivot might be useful for this?

This is the table to run the function against, with a few sample record results. Select versions from versiontable13.0,13.1,14.0,14.113.0,13.1,14.0,14.113.0,13.1,14.0,14.113.0,13.1,14.0,14.111.0,11.1,12.0,12.1,13.0,13.1,14.0

I tried this. Now it no longer recognises the function. Is the syntax wrong?select fn_Split(versions, ',') as SingleVersion from versiontable where versions is not nullServer: Msg 195, Level 15, State 10, Line 1'fn_Split' is not a recognized function name.

Tried this also.select dbo.fn_Split(versions, ',') as Version from versiontable where versions is not nullServer: Msg 208, Level 16, State 1, Line 1Invalid object name 'dbo.fn_Split'.

Any suggestions to get the query to work or even better, a nifty method to accomplish this within my data flow task using one of the Data Flow Transformation. Seems like the pivot might be useful for this?

What do you get when you run the following?

SELECT *FROM sys.Objects WHERE Name = 'fn_Split'

If the answer is nothing, then you're either in the wrong database or the CREATE FUNCTION code didn't actually work.

As a side bar, you'd probably get a lot more "hits" on your question if you asked it in the proper forum instead of a thread dedicated to the discusssion of an article.

--Jeff Moden"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T."--22 Aug 2013