• It would be interesting to do a large performance test and find out if "performance" using this method belongs in the "Pro" or "Con" column.

    I also concern myself with such things as the "pipe". For example, the code (without the ROWS tag pair just to be fair) from the article takes 136 characters to depict 3 people by first name and salary...

    136 characters with spaces

    <ROW Name="Richard" Salary="1100"/> <ROW Name="Cliff" Salary="1200"/> <ROW Name="Donna" Salary="13000"/> <ROW Name="Ann" Salary="1500"/>

    As a tab delimited parameter, it only takes 37 characters...

    Richard1100Cliff1200Donna13000Ann1500

    Doing the math of (136-37)/37 we come up with a ratio of about 2.7 (and this is the simpler of the two forms of XML). Put another way, you can pass 2.7 times more traffic in the same amount of time using TAB delimited data than you can even with such simple XML. Also, it's been demonstrated many times on many threads on SSC that shredding XML is quite a bit slower than splitting TAB delimited parameters even if you use a WHILE loop to split one of the "blob" datatypes (which can also hold up to 2 Gig). It all get's even slower if you want to correctly shred XML bearing special characters. It's also much easier to form TAB delimited parameters on the GUI side of the house than it is XML (as stated in the article).

    Although the article was well written, I see no redeeming qualities to passing XML parameters.

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

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)