Probably because binary data was easy to put in and easy to get out, but what you put in is not what you get out. There are also performance implications with binary data, it's usually more secure to store as base64 in a varchar(max) or text. Absolutely no reason to store in an unicode column. Davy
Sent from my iPhone > On 10 Sep 2015, at 09:47, Greg Low (罗格雷格博士) <[email protected]> wrote: > > 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>
