>From my experience there usually is no good reason for this sort of thing. I've seen people attempt to store phone numbers as a number and surely most here have seen similar things.
On Thursday, 10 September 2015, 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] > <javascript:;>> 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] > <javascript:;>> 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] > <javascript:;>> 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] > <javascript:;>> 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] <javascript:;> [mailto: > [email protected] <javascript:;>] > >>> On Behalf Of Thomas Koster > >>> Sent: Thursday, 10 September 2015 10:33 AM > >>> To: ozDotNet <[email protected] <javascript:;>> > >>> Subject: Re: Odd text encoding > >>> > >>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <[email protected] > <javascript:;>> 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> >
