opc.three (7/1/2013)
SELECT CAST('>>' AS XML) AS [Search and Replace?];
Well, yes and no ;-).
Yes = in that scenario it would be impossible to get back to the source string.
No = that scenario is not what happens with the code I submitted previously since the ampersand would have been escaped, leaving ">>", which could be translated back as long as you do the "&" -> "&" replacement last.
PS I can appreciate the trouble you went to in creating your post so things would appear as you intended. I end up using the HTML hex codes on a regular basis to get the output I need, which I had to do for this post as well.
It seems that maybe the real issue is that the "&" gets translated when posting. If you look at your quote of my text in your last posting, it has the actual <, >, and & characters instead of the encoded values from my post. Your usage of "&" seems to survive longer so I will switch to using that instead of "&". Thanks for the suggestion! 🙂
Take care,
Solomon...
SQL# — https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
Sql Quantum Lift — https://SqlQuantumLift.com/ ( company )
Sql Quantum Leap — https://SqlQuantumLeap.com/ ( blog )
Info sites — Collations • Module Signing • SQLCLR