Re: Odd text encoding

[Thomas Koster]

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 (罗格雷格博士)  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  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 (罗格雷格博士)  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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
>> On Behalf Of Thomas Koster
>> Sent: Thursday, 10 September 2015 10:33 AM
>> To: ozDotNet 
>> Subject: Re: Odd text encoding
>>
>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士)  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:
>> > H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
>>
>> 

Cross-platform charting

[Greg Keogh]

Hi Folks, I may have found a use for JavaScript (I can hear people falling
out of their chairs from here!) ... indirectly. I'm keen to hear if anyone
is doing what I'm about to try.

My Xamarin generated app for phones on 3 platforms has to display charts
and gauges of various types. I went looking for libraries to do this and
found a variety with differing reputations and forum arguments about their
pros and cons. I found Syncfusion for Xamarin which is a technical work of
art and has renders for all 3 platforms that are single-line additions,
then you feed the data in an off you go. I had it working in an hour, and I
emailed them to confirm the price on their web link was actually $US99. No
reply, but I noticed 3 days later that the price list has updated to show
the price is actually $US1995, and the $99 is for the iOS target only.
Methinks it was a mistake. So I've deleted Syncfusion.

Ok, now for some lateral thinking: get "someone else" to draw the charts
for me. Candidates are Google Charts 
and the Microsoft equivalent (I've lost it, what's it called ... ANYONE?!).

In the mobile apps I feed the data as JavaScript arrays into HTML and show
it in the WebView control which works easily on all platforms. So on online
service is doing all the rendering for me.

I'm just about to try the Google one, but I thought I'd ask for comments.

*Greg K*

Re: Cross-platform charting

[Joseph Cooney]

I've had good success in the past with flotr2

http://www.humblesoftware.com/flotr2/

On Thu, Sep 10, 2015 at 5:40 PM, Jorke Odolphi  wrote:

> Depends if they were sitting on chairs..
>
> I’ve had great success with - http://d3js.org/ -it covers that platforms
> i’ve needed to address: http://caniuse.com/#feat=svg
>
> The learning curve can be pretty steep – but I sense you seem to enjoy
> that :)
>
>
> From:  on behalf of Greg Keogh
> Reply-To: ozDotNet
> Date: Thursday, 10 September 2015 5:19 pm
> To: ozDotNet
> Subject: Cross-platform charting
>
> Hi Folks, I may have found a use for JavaScript (I can hear people falling
> out of their chairs from here!) ... indirectly. I'm keen to hear if anyone
> is doing what I'm about to try.
>
> My Xamarin generated app for phones on 3 platforms has to display charts
> and gauges of various types. I went looking for libraries to do this and
> found a variety with differing reputations and forum arguments about their
> pros and cons. I found Syncfusion for Xamarin which is a technical work of
> art and has renders for all 3 platforms that are single-line additions,
> then you feed the data in an off you go. I had it working in an hour, and I
> emailed them to confirm the price on their web link was actually $US99. No
> reply, but I noticed 3 days later that the price list has updated to show
> the price is actually $US1995, and the $99 is for the iOS target only.
> Methinks it was a mistake. So I've deleted Syncfusion.
>
> Ok, now for some lateral thinking: get "someone else" to draw the charts
> for me. Candidates are Google Charts
>  and the Microsoft equivalent (I've
> lost it, what's it called ... ANYONE?!).
>
> In the mobile apps I feed the data as JavaScript arrays into HTML and show
> it in the WebView control which works easily on all platforms. So on online
> service is doing all the rendering for me.
>
> I'm just about to try the Google one, but I thought I'd ask for comments.
>
> *Greg K*
>



-- 

w: http://jcooney.net
t: @josephcooney

Re: Odd text encoding

[Mark Hurd]

Note that the original XML would have been smaller than the base64
compressed text if you removed the unused namespaces :-) (Of course it
presumably would have compressed to smaller again.)

-- 
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)


On 10 September 2015 at 15:32, Nelson  wrote:
> Stephen,
>
> That base64 encoding - see https://en.wikipedia.org/wiki/Base64
> the == at the end is for padding.
>
>
> base64 is a common way to encode binary data in plaintext string (gzip in
> this our case here)
>
>
> Regards,
>
> Nelson Chan
>
> On 10 September 2015 at 15:55, Stephen Price 
> 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 (罗格雷格博士)  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: ozdotnet-boun...@ozdotnet.com
>>> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Thomas Koster
>>> Sent: Thursday, 10 September 2015 10:33 AM
>>> To: ozDotNet 
>>> Subject: Re: Odd text encoding
>>>
>>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
>>> 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:
>>> > H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
>>>
>>> 
>
>



-- 
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)

Re: Cross-platform charting

[Corneliu I. Tusnea]

Have you looked at http://www.highcharts.com/ ? Don't know if it works with
Xamarin but the graphics part is pretty damn nice :)


On Thu, Sep 10, 2015 at 5:52 PM, Joseph Cooney 
wrote:

> I've had good success in the past with flotr2
>
> http://www.humblesoftware.com/flotr2/
>
> On Thu, Sep 10, 2015 at 5:40 PM, Jorke Odolphi  wrote:
>
>> Depends if they were sitting on chairs..
>>
>> I’ve had great success with - http://d3js.org/ -it covers that platforms
>> i’ve needed to address: http://caniuse.com/#feat=svg
>>
>> The learning curve can be pretty steep – but I sense you seem to enjoy
>> that :)
>>
>>
>> From:  on behalf of Greg Keogh
>> Reply-To: ozDotNet
>> Date: Thursday, 10 September 2015 5:19 pm
>> To: ozDotNet
>> Subject: Cross-platform charting
>>
>> Hi Folks, I may have found a use for JavaScript (I can hear people
>> falling out of their chairs from here!) ... indirectly. I'm keen to hear if
>> anyone is doing what I'm about to try.
>>
>> My Xamarin generated app for phones on 3 platforms has to display charts
>> and gauges of various types. I went looking for libraries to do this and
>> found a variety with differing reputations and forum arguments about their
>> pros and cons. I found Syncfusion for Xamarin which is a technical work of
>> art and has renders for all 3 platforms that are single-line additions,
>> then you feed the data in an off you go. I had it working in an hour, and I
>> emailed them to confirm the price on their web link was actually $US99. No
>> reply, but I noticed 3 days later that the price list has updated to show
>> the price is actually $US1995, and the $99 is for the iOS target only.
>> Methinks it was a mistake. So I've deleted Syncfusion.
>>
>> Ok, now for some lateral thinking: get "someone else" to draw the charts
>> for me. Candidates are Google Charts
>>  and the Microsoft equivalent
>> (I've lost it, what's it called ... ANYONE?!).
>>
>> In the mobile apps I feed the data as JavaScript arrays into HTML and
>> show it in the WebView control which works easily on all platforms. So on
>> online service is doing all the rendering for me.
>>
>> I'm just about to try the Google one, but I thought I'd ask for comments.
>>
>> *Greg K*
>>
>
>
>
> --
>
> w: http://jcooney.net
> t: @josephcooney
>

Re: Odd text encoding

[Davy Jones]

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 (罗格雷格博士)  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  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 (罗格雷格博士)  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  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 (罗格雷格博士)  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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
 On Behalf Of Thomas Koster
 Sent: Thursday, 10 September 2015 10:33 AM
 To: ozDotNet 
 Subject: Re: Odd text encoding
 
> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士)  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:
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
 
 

Re: Cross-platform charting

[Jorke Odolphi]

Depends if they were sitting on chairs..

I’ve had great success with - http://d3js.org/ -it covers that platforms i’ve 
needed to address: http://caniuse.com/#feat=svg

The learning curve can be pretty steep – but I sense you seem to enjoy that :)


From: > on 
behalf of Greg Keogh
Reply-To: ozDotNet
Date: Thursday, 10 September 2015 5:19 pm
To: ozDotNet
Subject: Cross-platform charting

Hi Folks, I may have found a use for JavaScript (I can hear people falling out 
of their chairs from here!) ... indirectly. I'm keen to hear if anyone is doing 
what I'm about to try.

My Xamarin generated app for phones on 3 platforms has to display charts and 
gauges of various types. I went looking for libraries to do this and found a 
variety with differing reputations and forum arguments about their pros and 
cons. I found Syncfusion for Xamarin which is a technical work of art and has 
renders for all 3 platforms that are single-line additions, then you feed the 
data in an off you go. I had it working in an hour, and I emailed them to 
confirm the price on their web link was actually $US99. No reply, but I noticed 
3 days later that the price list has updated to show the price is actually 
$US1995, and the $99 is for the iOS target only. Methinks it was a mistake. So 
I've deleted Syncfusion.

Ok, now for some lateral thinking: get "someone else" to draw the charts for 
me. Candidates are Google Charts and the 
Microsoft equivalent (I've lost it, what's it called ... ANYONE?!).

In the mobile apps I feed the data as JavaScript arrays into HTML and show it 
in the WebView control which works easily on all platforms. So on online 
service is doing all the rendering for me.

I'm just about to try the Google one, but I thought I'd ask for comments.

Greg K

Re: Odd text encoding

[罗格雷格博士]

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  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 (罗格雷格博士)  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  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 (罗格雷格博士)  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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
>>> On Behalf Of Thomas Koster
>>> Sent: Thursday, 10 September 2015 10:33 AM
>>> To: ozDotNet 
>>> Subject: Re: Odd text encoding
>>> 
 On 10 September 2015 at 10:21, Greg Low (罗格雷格博士)  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:
 H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
>>> 
>>> 

Re: Cross-platform charting

[Greg Keogh]

>
> Have you looked at http://www.highcharts.com/ ? Don't know if it works
> with Xamarin but the graphics part is pretty damn nice :)
>

Since I've been searching this afternoon, I now realise how popular this
ecosystem is. For us, highcharts will be several hundred dollars, but
that's peanuts if it pays off (a decision for the boss). The hard part is
now comparing all the options. For me it's coding ease and clarity, it will
come down to which one has the neatest and easiest way of converting raw
data into pictures. Some sort of REST API would be nice to roundtrip the
pieces.

I'm actually quite excited by the idea of letting someone else do the heavy
number crunching and rendering. The product I'm working on has some custom
chart drawing done via decades of work in C++ and some is done with .NET
ComponentOne and Visifire, so it's quite sobering to think that all of that
work and the expensive libraries could soon be overtaken by an online
service. This is the future...

*Greg K*

Re: Odd text encoding

[Nelson]

I cant understand why they don't just store the XML in the ntext column
directly in the first place...
maybe someone was hoping that gzip run can save some size?

Re Davy:
>> There are also performance implications with binary data,
I think its quite the contrary, there is an extra step involved going to &
from base64 and binary.

>> it's usually more secure to store as base64
oh god not again. base64 is just a representation of the data in printable
ASCII characters. -  think binary (base2), hex (base8) :)
base64 has absolutely nothing to do with security.

if security is what you are after, use proper encryption such as AES on the
original data, then base64 the output if you need to send/store as text



Nelson Chan

On 10 September 2015 at 19:50, Davy Jones  wrote:

> 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 (罗格雷格博士)  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  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 (罗格雷格博士) 
> 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 
> 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 (罗格雷格博士) 
> 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: ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com]
>  On Behalf Of Thomas Koster
>  Sent: Thursday, 10 September 2015 10:33 AM
>  To: ozDotNet 
>  Subject: Re: Odd text encoding
> 
> > On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
> 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:
> >
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
> 
>  
>

Re: Odd text encoding

[David Rhys Jones]

I cant understand why they don't just store the XML in the ntext column
directly in the first place...
maybe someone was hoping that gzip run can save some size?

Re Davy:
>> There are also performance implications with binary data,
>I think its quite the contrary, there is an extra step involved going to &
from base64 and binary.

Database performance, high critical databases it's faster to write text
than binary, this might have changed with the last version of SQL but it
was true up until '2008

>> it's usually more secure to store as base64
>oh god not again. base64 is just a representation of the data in printable
ASCII characters. -  think binary (base2), hex (base8) :)
>base64 has absolutely nothing to do with security.

>if security is what you are after, use proper encryption such as AES on
the original data, then base64 the output if you need >to send/store as text

Completely missed my point, I'm not talking about encryption at all,  it's
more secure to store as base64, as you don't get problems trying to get the
data back out. Just that what you put in is what you are getting out,
without strange driver problems or Collation issues.

Davy.




*Si hoc legere scis nimium eruditionis habes*.


On Thu, Sep 10, 2015 at 12:00 PM, Nelson  wrote:

> I cant understand why they don't just store the XML in the ntext column
> directly in the first place...
> maybe someone was hoping that gzip run can save some size?
>
> Re Davy:
> >> There are also performance implications with binary data,
> I think its quite the contrary, there is an extra step involved going to &
> from base64 and binary.
>
> >> it's usually more secure to store as base64
> oh god not again. base64 is just a representation of the data in printable
> ASCII characters. -  think binary (base2), hex (base8) :)
> base64 has absolutely nothing to do with security.
>
> if security is what you are after, use proper encryption such as AES on
> the original data, then base64 the output if you need to send/store as text
>
>
>
> Nelson Chan
>
> On 10 September 2015 at 19:50, Davy Jones  wrote:
>
>> 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 (罗格雷格博士)  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  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 (罗格雷格博士) 
>> 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 
>> 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 (罗格雷格博士) 
>> 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: ozdotnet-boun...@ozdotnet.com [mailto:
>> ozdotnet-boun...@ozdotnet.com]
>>  On Behalf Of Thomas Koster
>>  Sent: Thursday, 10 September 2015 10:33 AM
>>  To: ozDotNet 
>>  Subject: Re: Odd text encoding
>> 
>> > On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
>> wrote:
>> > This one’s driving me crazy and I 

Re: Odd text encoding

[Greg Keogh]

>
> i think ive read it somewhere, a rule of thumb is if you dont need to do
> calculations with your "number", make it a string
>
In 2006 where I was working they created a new SQL DB and the natural key
of the most important table was a 12 digit number (customer number I think)
and there were arguments about if the PK should be a string or a number.
For some reason they chose a DECIMAL(12,0) which vaguely worried me, but I
didn't get involved and I still wonder if a 64-bit integer would have been
better, or even a CHAR(12) ... still dunno.

*GK*

Re: Odd text encoding

[Nelson]

Yea the phone number thing *facepalm*
ask them how they gonna store 000 as number.

i think ive read it somewhere, a rule of thumb is if you dont need to do
calculations with your "number", make it a string
On 10 Sep 2015 21:13, "DotNet Dude"  wrote:

> >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 (罗格雷格博士) 
> 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  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 (罗格雷格博士) 
>> 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 
>> 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 (罗格雷格博士) 
>> 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: ozdotnet-boun...@ozdotnet.com [mailto:
>> ozdotnet-boun...@ozdotnet.com]
>> >>> On Behalf Of Thomas Koster
>> >>> Sent: Thursday, 10 September 2015 10:33 AM
>> >>> To: ozDotNet 
>> >>> Subject: Re: Odd text encoding
>> >>>
>>  On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
>> 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:
>> 
>> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
>> >>>
>> >>> 
>>
>

Re: Odd text encoding

[DotNet Dude]

>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 (罗格雷格博士)  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  > 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 (罗格雷格博士)  > 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  > 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 (罗格雷格博士)  > 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: ozdotnet-boun...@ozdotnet.com  [mailto:
> ozdotnet-boun...@ozdotnet.com ]
> >>> On Behalf Of Thomas Koster
> >>> Sent: Thursday, 10 September 2015 10:33 AM
> >>> To: ozDotNet >
> >>> Subject: Re: Odd text encoding
> >>>
>  On 10 September 2015 at 10:21, Greg Low (罗格雷格博士)  > 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:
>  H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
> >>>
> >>> 
>

Re: Odd text encoding

[Greg Harris]

Oh Yeah!

Friday rant to follow...

>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.
>Yea the phone number thing *facepalm*
>ask them how they gonna store 000 as number.
>i think ive read it somewhere, a rule of thumb is if you dont need to do
calculations with your "number", make it a string

Several years ago we were working on a soft copy bill delivery system for
one of the telcos.
The specification I wrote said that the phone number was a text field with
a maximum length of some large number.

The vendor who wrote the analysis software for us saw NUMBER looked at a
few of them and said IT MUST BE AN INTEGER!
and besides integers are small and fast to process => good.
When you dialled special numbers, text would be put in the field, like
"000" became "Emergency Services"
Or for an international number the international prefix would be replaced
by a "+".
They got very upset when they ran through the bulk of the test data we gave
them with the specification and many of them failed!

Yes I think that I agree with the comment "a rule of thumb is if you don't
need to do calculations with your "number", make it a string"

I may reword that as if the number is a measurement, it probably is best
being a numeric, if it is a business generated identification it is
probably best being a string.

Have fun

Greg #27

Re: Odd text encoding

[Thomas Koster]

On 10 September 2015 at 22:09, David Rhys Jones  wrote:
> Database performance, high critical databases it's faster to write text than
> binary, this might have changed with the last version of SQL but it was true
> up until '2008

Binary data is naturally faster to copy and compare than text because
processing text must always consider encodings and collations, and
sometimes line endings too, whereas binary data is copied with memcpy
and compared with memcmp.

If binary values are slower in a particular DBMS, then that
implementation has added some artificial costs to using binary data
(for example, by allowing varchar but not varbinary to be stored
directly in the leaves of the b-tree).

Base-64-encoding a value also increases its storage size by 33%. That is
a significant overhead that reaches beyond the DBMS, with equally
significant potential to affect many performance metrics (e.g. more CPU
cache misses, more OS buffer cache misses, more page faults, more I/O
everywhere, higher infrastructure costs).

> it's more secure to store as base64, as you don't get problems trying to get
> the data back out. Just that what you put in is what you are getting out,
> without strange driver problems or Collation issues.

Base-64-encoded values are *text*. If you store base-64-encoded values
inside a database, you are actually introducing an additional risk of
text-encoding and collation problems when there previously was none.

In my view, there is never a good reason to store base-64-encoded values
in a database system that has a varbinary (or equivalent) data type.

--
Thomas Koster

RE: Odd text encoding

[罗格雷格博士]

The thing to understand with databases like SQL Server is that as soon as you 
start comparing and/or joining values, you really hope that they are integers 
(or bigints). If I had a 12 digit number that was a customer number, I’d just 
be using a bigint.

As soon as you start comparing character values, things get slow. It might seem 
simple to write a statement like

WHERE Somecolumn = ‘A’

But unfortunately, that’s not a simple comparison. SQL Server has to apply all 
the rules for the specified collation, and then do that column by column. It’s 
a relatively big job, certainly nothing like “are these two integers the same 
value?”.

I was at a site recently where they were changing all the IDs from bigint to 
uniqueidentifier (GUID), not for any real GUID-related reason, but because they 
were concerned about the possibility of running out of bigint values. (Clearly 
it’s a pity more maths isn’t taught at schools).

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

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Thursday, 10 September 2015 10:12 PM
To: ozDotNet 
Subject: Re: Odd text encoding


i think ive read it somewhere, a rule of thumb is if you dont need to do 
calculations with your "number", make it a string
In 2006 where I was working they created a new SQL DB and the natural key of 
the most important table was a 12 digit number (customer number I think) and 
there were arguments about if the PK should be a string or a number. For some 
reason they chose a DECIMAL(12,0) which vaguely worried me, but I didn't get 
involved and I still wonder if a 64-bit integer would have been better, or even 
a CHAR(12) ... still dunno.

GK

Re: Odd text encoding

[罗格雷格博士]

SQL Server is fine writing and reading binary data. We store gzipped xml and 
text in varbinary(max) columns all the time.

But even for text, ntext is the wrong choice. In this case varchar(max) is 
probably what they should be using for base64 text.

Regards

Greg

Dr Greg Low
SQL Down Under
+61 419201410
1300SQLSQL (1300775775)

On 10 Sep 2015, at 10:09 pm, David Rhys Jones 
> wrote:

I cant understand why they don't just store the XML in the ntext column 
directly in the first place...
maybe someone was hoping that gzip run can save some size?

Re Davy:
>> There are also performance implications with binary data,
>I think its quite the contrary, there is an extra step involved going to & 
>from base64 and binary.

Database performance, high critical databases it's faster to write text than 
binary, this might have changed with the last version of SQL but it was true up 
until '2008

>> it's usually more secure to store as base64
>oh god not again. base64 is just a representation of the data in printable 
>ASCII characters. -  think binary (base2), hex (base8) :)
>base64 has absolutely nothing to do with security.

>if security is what you are after, use proper encryption such as AES on the 
>original data, then base64 the output if you need >to send/store as text

Completely missed my point, I'm not talking about encryption at all,  it's more 
secure to store as base64, as you don't get problems trying to get the data 
back out. Just that what you put in is what you are getting out, without 
strange driver problems or Collation issues.

Davy.




Si hoc legere scis nimium eruditionis habes.


On Thu, Sep 10, 2015 at 12:00 PM, Nelson 
> wrote:
I cant understand why they don't just store the XML in the ntext column 
directly in the first place...
maybe someone was hoping that gzip run can save some size?

Re Davy:
>> There are also performance implications with binary data,
I think its quite the contrary, there is an extra step involved going to & from 
base64 and binary.

>> it's usually more secure to store as base64
oh god not again. base64 is just a representation of the data in printable 
ASCII characters. -  think binary (base2), hex (base8) :)
base64 has absolutely nothing to do with security.

if security is what you are after, use proper encryption such as AES on the 
original data, then base64 the output if you need to send/store as text



Nelson Chan

On 10 September 2015 at 19:50, Davy Jones 
> wrote:
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 (罗格雷格博士) 
> > 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 
>> > 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 (罗格雷格博士) 
>>> > 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 
>>> > 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 (罗格雷格博士) 
 > 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 

RE: Odd text encoding

[罗格雷格博士]

How long would it take to insert that many rows? ☺

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

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Friday, 11 September 2015 10:15 AM
To: ozDotNet 
Subject: Re: Odd text encoding

but because they were concerned about the possibility of running out of bigint 
values. (Clearly it’s a pity more maths isn’t taught at schools).

My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63 
non-stop it will take 5444 years -- GK

Re: Odd text encoding

[Greg Keogh]

>
> but because they were concerned about the possibility of running out of
> bigint values. (Clearly it’s a pity more maths isn’t taught at schools).
>

My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63
non-stop it will take 5444 years -- *GK*

RE: Odd text encoding

[Ken Schaefer]

Security is more than just permitting/denying access. Security is also about 
maintaining your data’s integrity/fidelity. I think that’s what Davy was 
alluding to.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Nelson
Sent: Thursday, 10 September 2015 8:00 PM
To: ozDotNet 
Subject: Re: Odd text encoding


>> it's usually more secure to store as base64
oh god not again. base64 is just a representation of the data in printable 
ASCII characters. -  think binary (base2), hex (base8) :)
base64 has absolutely nothing to do with security.

if security is what you are after, use proper encryption such as AES on the 
original data, then base64 the output if you need to send/store as text



Nelson Chan

On 10 September 2015 at 19:50, Davy Jones 
> wrote:
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 (罗格雷格博士) 
> > 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 
>> > 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 (罗格雷格博士) 
>>> > 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 
>>> > 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 (罗格雷格博士) 
 > 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: ozdotnet-boun...@ozdotnet.com 
 [mailto:ozdotnet-boun...@ozdotnet.com]
 On Behalf Of Thomas Koster
 Sent: Thursday, 10 September 2015 10:33 AM
 To: ozDotNet >
 Subject: Re: Odd text encoding

> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
> > 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:
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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

RE: Odd text encoding

[Ken Schaefer]

And what would those numbers have looked like 2 years ago? 4 years ago? 10 
years ago?

Assuming computing power doubles every 18-24 months, then that 5444 years will 
become a lot less, relatively quickly.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Friday, 11 September 2015 10:15 AM
To: ozDotNet 
Subject: Re: Odd text encoding

but because they were concerned about the possibility of running out of bigint 
values. (Clearly it’s a pity more maths isn’t taught at schools).

My PC can do a for int loop up to 2^30 in about 20 seconds. To get to 2^63 
non-stop it will take 5444 years -- GK

Re: Odd text encoding

[Nelson]

Stephen,

That base64 encoding - see https://en.wikipedia.org/wiki/Base64
the == at the end is for padding.


base64 is a common way to encode binary data in plaintext string (gzip in
this our case here)


Regards,

Nelson Chan

On 10 September 2015 at 15:55, Stephen Price 
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 (罗格雷格博士)  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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
>> On Behalf Of Thomas Koster
>> Sent: Thursday, 10 September 2015 10:33 AM
>> To: ozDotNet 
>> Subject: Re: Odd text encoding
>>
>> On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
>> 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:
>> > H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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
>>
>> 
>>
>

Re: Odd text encoding

[罗格雷格博士]

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 
> 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 (罗格雷格博士) 
> 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: ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Thomas Koster
Sent: Thursday, 10 September 2015 10:33 AM
To: ozDotNet >
Subject: Re: Odd text encoding

On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) 
> 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:
> H4sIAAAEALVW0W7aMBT9lanvre0wBkNtJEo3DWkFBGGvyDiXYi22M9vpYL/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