I was worried the consuming applications might not like the xml without that header. Maybe that's not an issue.

I've also pretty much decided I need to write this utility...

Should I just base64 encode the data before I string it out then?

Got it. Thanks again! I thought that was the point of the "cdata". I thought that was essentially "escaping" it for me.

Here's what I seeing in that substring: select substring(cast(@MyData as varchar(max)), 5050, 50)

rb_OELM{€B=_OJCt|SCHHK\j}S8bNRKp|a=UHQD{tHBR_JKmt[

Hmm, not so fast, my code seems to work against simple test data, but when I try to run it against some real production data, seems to be having some...

Works perfectly, thanks much!

Yes, that was exactly the problem. That's what I meant to do in the first place.

Thank you very much HappyCat59!

You are exactly right Mike! Thank You!!

There must be a conflict in the data, but I'm not seeing it.

Well that's strange. But now that you mention it, I think this query worked in the past.

So I guess the old saying is true then: "no matter where you go, there you are". I guess I should always express litteral times in UTC format, regardless of...

That sounds like it's worth a shot. I'm just surprised there's no existing function that handles this. I'm sure there's a reason, but I don't know what it is.

Thanks sturner.

A wonderful solution indeed if what I needed to do was get the date/time. Unfortunately, I'm trying to figure out how to store the date/time.

Yes, I wish changing the table was an option, but it's just not right now. I'm stuck with it. :hehe:

I guess a permanent tally makes the most sense. The cte tally table is nice for my situation, but I'll probably need it again before long. Thanks!