The data was stored by Biztalk, and of course it shoved binary data into an ntext data type column. The next two questions are:
1. Why put base 64 encoded data into an ntext (unicode) column when such a limited range of values can be generated? 2. Why use a deprecated data type (ntext) in the first place? I'm sure that both questions are above my paygrade :-) Regards Greg Dr Greg Low SQL Down Under +61 419201410 1300SQLSQL (1300775775) > On 10 Sep 2015, at 5:10 pm, Thomas Koster <[email protected]> wrote: > > It is strange that base-64 encoding is even used here at all. Surely > proper binary data types have been available in relational databases > since the dark ages? > -- > Thomas Koster > > >> On 10 September 2015 at 16:40, Greg Low (罗格雷格博士) <[email protected]> wrote: >> That was my first reaction too. Haven't spent time staring at base64 >> encoding for a long time. Knew someone would recognise it though. The brains >> trust comes through again! >> >> Regards >> >> Greg >> >> Dr Greg Low >> SQL Down Under >> +61 419201410 >> 1300SQLSQL (1300775775) >> >> On 10 Sep 2015, at 3:55 pm, Stephen Price <[email protected]> wrote: >> >> How did you get my Azure certificate? wtf?? >> >> Seriously though, the trailing == on the end (plus the overall look) makes >> it look exactly like an Azure publish certificate. >> >>> On Thu, 10 Sep 2015 at 08:39 Greg Low (罗格雷格博士) <[email protected]> wrote: >>> >>> Perfect thanks Thomas. >>> >>> I'll just have to add a base64 decode function and I should be fine. >>> >>> Regards, >>> >>> Greg >>> >>> Dr Greg Low >>> >>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 >>> fax >>> SQL Down Under | Web: www.sqldownunder.com >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] >>> On Behalf Of Thomas Koster >>> Sent: Thursday, 10 September 2015 10:33 AM >>> To: ozDotNet <[email protected]> >>> Subject: Re: Odd text encoding >>> >>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <[email protected]> wrote: >>>> This one’s driving me crazy and I thought the brains trust might have >>>> an idea. >>>> >>>> Here’s a value that’s stored in an ntext column in a SQL Server DB: >>>> H4sIAAAAAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/Wh33Sfm >>>> GGJASatKOS95KH3HvPyTk+tvPn6fe1NLg3Bas5PMIsS0H3GVOZtJGm0lBmuZJfuLFKb99t >>>> RCJNzw3cXKytTXsIGbYGQc2V4Ewro1b2iimBZj8SFGDcRbiNom0K8UQrBnGmwaB4qS4OQI >>>> S8AakCmYLJEjsDu4dD5dffg1iC/sZjUF+5/F7RdP2zTEAbJWlyB5byxFRc7/1zFQsyjEFa >>>> vuKM7takYmz/N8ZZJgTV24rqo3+qfeSG8hGMFU7fON2JO/KTeDX09YBXrB3/QgdKWsdWCw >>>> zxwjVPY2qhH8euZOocH3xwmHTxAHaRgjTOswXNbVwsaUIlg6CiC7xs61zSZK0k1AX9g8CB >>>> txDBaAaa04T/2m8ZdDTvJcn5FxYHAjXmp9JxxdHymaFyR6bAnCCXpZg/3yhvOZXPzGxEN3 >>>> vnav57ydMp1y01nNUX2quLkzy6ZxwAgRc3TwLy0o1BvB7gcwNaUgH1PBIv12Au6ZNwGkol >>>> 4f4fIl3kOkfZ7hm2MOm0OteooVS0F6swcHAPzvuwPxjM70k58bxaDB2t2aE0GI+i6fB2Hg >>>> 3Ho3K8qa8OcedKn7USYYBJ+xJ3LjFpADh0NQNEqhjvOoQXxl1PaRLd5DaMV0c9IcH44FVz >>>> x6lrjS6f1vK359184V9pkluuCgoAAA== >>>> >>>> Somehow, that’s apparently meant to be either a) an XML file, or b) a >>>> GZipped XML file. >>> >>> echo "H4s...." | base64 -d | gunzip >>> >>> <snip>
