Prev: Top 10 Technical requirements for In-Memory Reporting
Next: Understanding this query
From: John Hurley on 29 May 2010 18:30
Frank:

> Why would you switch to Unicode? Why not to WE8MSWIN1252? anything MS
> Windows can throw at you is supported. And databases generally store
> whatever you feed them (code points! Not characters).

+1

> Apart from the obvious length problems, there are the bugs introduces by
> the fact you use a variable length character set.
> If any, I'd go for a fixed length set, like AL16UTF16 (which also
> better aligns with Java, and MS Windows - the latter using UCS2,
> which is regarded a forerunner of UTF16)

+1
From: Walt on 2 Jun 2010 11:10
Frank van Bortel wrote:

>
> Why would you switch to Unicode? Why not to WE8MSWIN1252? anything MS
> Windows can throw at you is supported.

Good question. WE8MSWIN1252 seems to solve most of our immediate
problems, and we have plans to support multiple languages so UTF-8 may
be overkill. In favor of UTF-8 is that there is some appeal in solving
the problem "permanently", and of course there's the grumbling from the
usual suspects about adopting a M$ standard. (c:

This seems a viable solution, and we'll explore it further. Thanks.

//Walt
From: Walt on 2 Jun 2010 11:18
Walt wrote:
> ...and we have plans to support multiple languages...

should be:

....and we have NO plans to support multiple languages....

//Walt
From: John Hurley on 2 Jun 2010 11:19
Walt:

> Good question.  WE8MSWIN1252 seems to solve most of our immediate
> problems, and we have plans to support multiple languages so UTF-8 may
> be overkill.  In favor of UTF-8 is that there is some appeal in solving
> the problem "permanently", and of course there's the grumbling from the
> usual suspects about adopting a M$ standard.  (c:

For 64 bit Oracle on linux systems ( such as OEL 5.4 ) ... when you
create a database the WE8MSWIN1252 is the default for NLS_CHARACTERSET
and AL16UTF16 is the default for NLS_NCHAR_CHARACTERSET ...

So you can always go with the argument that you are just taking the
Oracle recommended defaults ... and stay away from the whole other
vendor.



From: Frank van Bortel on 3 Jun 2010 14:56
On 06/02/2010 05:18 PM, Walt wrote:
> Walt wrote:
>> ...and we have plans to support multiple languages...
>
> should be:
>
> ...and we have NO plans to support multiple languages....
>
> //Walt

Even when so... If those languages do not require
Multi-Byte code points, stay away from it.

--

Regards,

Frank van Bortel
First  |  Prev  | 
Pages: 1 2
Prev: Top 10 Technical requirements for In-Memory Reporting
Next: Understanding this query