Re: Odd text encoding

*From:* ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Bec C > *Sent:* Friday, 11 September 2015 4:59 PM > > > *To:* ozDotNet <ozdotnet@ozdotnet.com> > *Subject:* Re: Odd text encoding > > > > I get your point Ken but is power real

Re: Odd text encoding

D,'cvml','ozdotnet-boun...@ozdotnet.com');>] *On > Behalf Of *Greg Keogh > *Sent:* Friday, 11 September 2015 10:15 AM > *To:* ozDotNet <ozdotnet@ozdotnet.com > <javascript:_e(%7B%7D,'cvml','ozdotnet@ozdotnet.com');>> > *Subject:* Re: Odd text encoding > > > >

Re: Odd text encoding

Ah but the issue is how many rows you can write into a table. That's a bit more work than a for loop :-) Regards Greg Dr Greg Low SQL Down Under +61 419201410 1300SQLSQL (1300775775) On 11 Sep 2015, at 5:16 pm, Greg Keogh > wrote: Assuming

Re: Odd text encoding

> > Assuming computing power doubles every 18-24 months, then that 5444 years >> will become a lot less, relatively quickly. >> > I didn't mention that counting to 2^63 is eminently parallelizable, so lets divide up a small fraction of the free internet computing power on the problem and see how

RE: Odd text encoding

going to get faster and faster over time. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Bec C Sent: Friday, 11 September 2015 4:59 PM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: Odd text encoding I get your point Ken but is power really incr

Re: Odd text encoding

5) 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 >> S

Re: Odd text encoding

t;> 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- >>&

Re: Odd text encoding

be fine. >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> Dr Greg Low >>>> >>>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 >>>> fax >>>> SQL Down Un

Re: Odd text encoding

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

Re: Odd text encoding

5 at 08:39 Greg Low (罗格雷格博士) <g...@greglow.com> > wrote: > >>>> > >>>> Perfect thanks Thomas. > >>>> > >>>> I'll just have to add a base64 decode function and I should be fine. > >>>> > >>>> Regards, >

Re: Odd text encoding

iling == 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 (罗格雷格博士) <g...@greglow.com> >> wrote: >> >>>> >

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

Re: Odd text encoding

;> >>> >> >>> Perfect thanks Thomas. >> >>> >> >>> I'll just have to add a base64 decode function and I should be fine. >> >>> >> >>> Regards, >> >>> >> >>> Greg >> >>

Re: Odd text encoding

gt; >>> > >>> Regards, > >>> > >>> Greg > >>> > >>> Dr Greg Low > >>> > >>> 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 > 4913 > >>> fax > >>> SQL Down Under

Re: Odd text encoding

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

Re: Odd text encoding

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

RE: Odd text encoding

et.com] On Behalf Of Greg Keogh Sent: Thursday, 10 September 2015 10:12 PM To: ozDotNet <ozdotnet@ozdotnet.com> 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 work

Re: Odd text encoding

gt; >>>> Regards, >>>> >>>> Greg >>>> >>>> Dr Greg Low >>>> >>>> 1300SQLSQL (1300 775 775) office | +61 419201410<tel:%2B61%20419201410> >>>> mobile│ +61 3 8676 4913<tel:%2B61%203%208676%20491

RE: Odd text encoding

t-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Friday, 11 September 2015 10:15 AM To: ozDotNet <ozdotnet@ozdotnet.com> 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)

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

:00 PM To: ozDotNet <ozdotnet@ozdotnet.com> 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 n

RE: Odd text encoding

Of Greg Keogh Sent: Friday, 11 September 2015 10:15 AM To: ozDotNet <ozdotnet@ozdotnet.com> 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 l

Re: Odd text encoding

> 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: oz

Re: Odd text encoding

ember 2015 10:33 AM To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>> Subject: Re: Odd text encoding On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com<mailto:g...@greglow.com>> wrote: > This one’s driving me crazy and I thought the brains tru

Odd text encoding

Hi Folks, 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:

RE: Odd text encoding

et.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low (??) Sent: Thursday, 10 September 2015 10:21 AM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Odd text encoding Hi Folks, This one’s driving me crazy and I thought the brains trust might have an idea. Here’s a value that’s stored

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: >

RE: Odd text encoding

...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Thomas Koster Sent: Thursday, 10 September 2015 10:33 AM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: Odd text encoding On 10 September 2015 at 10:21, Greg Low (罗格雷格博士) <g...@greglow.com> wrote: > This one’s driving

Re: Odd text encoding

; 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 <ozdotnet@ozdotnet.com> > Subject: Re: Odd text encoding > > On 10 September 2015 at 10:21, Greg Low (罗