From: "John Cowan" <[EMAIL PROTECTED]>
> > Are you saying that a value made up of twelve 16-byte values that was
> > actually six surrogates would be treated as:
> >
> > a) Six characters with unknown sort characteristics, or
> >
> > b) Twelve characters, at least six of which would have unknown s
On Mon, 7 Aug 2000, Michael (michka) Kaplan wrote:
> Are you saying that a value made up of twelve 16-byte values that was
> actually six surrogates would be treated as:
>
> a) Six characters with unknown sort characteristics, or
>
> b) Twelve characters, at least six of which would have unknow
ust 07, 2000 2:06 PM
Subject: RE: Encodings for SQL Databases
> From sorting point of view, given no actual official surrogate character
> assignment yet, the surrogate character sort key is more less undefined in
> 7.0. The data is not corrupted but is managed as part of undefined
catego
On 08/07/2000 03:45:42 PM addison wrote:
>Actually, the way surrogates work is: one high surrogate followed by one
>low surrogate. The second value would never, ever, coincide with a valid
>character (in the same way that bytes in UTF-8 multibyte characters never
>collide with valid ASCII values
.4762 (fax)
===
Globalization Engineering & Consulting Services
On Mon, 7 Aug 2000 [EMAIL PROTECTED] wrote:
> ((( Sorry to those who see a mangled subject. It should read "RE: Encodings
> for SQL Databases" )))
>
> Jon Peck wrote:
> > Most of
'r' please, ASAP.
Thanks,
Michael
-Original Message-
From: Michael (michka) Kaplan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 07, 2000 1:19 PM
To: Michael Kung; Unicode List
Subject: Re: Encodings for SQL Databases
I understand that part but you did not answer my question.
((( Sorry to those who see a mangled subject. It should read "RE: Encodings
for SQL Databases" )))
Jon Peck wrote:
> Most of the major databases now support Unicode at some
> level, but what is
> the best way to encode SQL statements for various database
> access apis? [
From: <[EMAIL PROTECTED]>
To: "Michael (michka) Kaplan" <[EMAIL PROTECTED]>
> > > b) Twelve characters, at least six of which would have unknown sort
> > > characteristics (since the first two bytes of a surrogate would not
have a
> > > defined sort order and the second two byte which might rando
> >
> > b) Twelve characters, at least six of which would have unknown sort
> > characteristics (since the first two bytes of a surrogate would not have a
> > defined sort order and the second two byte which might randomly coincide
> > with an existing BMP value when treated as a separate Unicode
t; <[EMAIL PROTECTED]>
To: "Unicode List" <[EMAIL PROTECTED]>
Sent: Monday, August 07, 2000 1:06 PM
Subject: Re: Encodings for SQL Databases
> I understand that part but you did not answer my question. :-)
>
> Are you saying that a value made up of twelve 16-byte
SQL 7.0, (b) was the case. I would LOVE to be incorrect on this point
though.
michka
- Original Message -
From: "Michael Kung" <[EMAIL PROTECTED]>
To: "Unicode List" <[EMAIL PROTECTED]>
Sent: Monday, August 07, 2000 12:52 PM
Subject: RE: Encodings for SQL
[mailto:[EMAIL PROTECTED]]
Sent: Monday, August 07, 2000 9:01 AM
To: Unicode List
Subject: Re: Encodings for SQL Databases
From: <[EMAIL PROTECTED]>
> According to the online help of SQL Server 7.0, you have to
> use the syntax N'abc' to write a Unicode literal in a SQL
> st
nicode List"
<[EMAIL PROTECTED]>
Sent: Monday, August 07, 2000 12:56 PM
Subject: RE: Encodings for SQL Databases
> SQLServer 7.0 and SQLServer 2000 are surrogate safe on the
> NCHAR/NVARCHAR/NTEXT storage. Not until the ISO standard accepts the
> surrogate assignment, any surro
From: <[EMAIL PROTECTED]>
> According to the online help of SQL Server 7.0, you have to
> use the syntax N'abc' to write a Unicode literal in a SQL
> statement.
>
> The N prefix echoes the N in NCHAR and NVARCHAR, and
>parallels the L"abc" syntax of C (but I wonder, what's that "N"
> for? One wou
((( Sorry to those who see a mangled subject. It should read "RE: Encodings
for SQL Databases" )))
Jon Peck wrote:
> Most of the major databases now support Unicode at some
> level, but what is
> the best way to encode SQL statements for various database
> access apis? [
t;
To: "Unicode List" <[EMAIL PROTECTED]>
Sent: Monday, August 07, 2000 7:43 AM
Subject: Encodings for SQL Databases
> Most of the major databases now support Unicode at some level, but what is
> the best way to encode SQL statements for various database access apis?
Is
> utf-
Most of the major databases now support Unicode at some level, but what is
the best way to encode SQL statements for various database access apis? Is
utf-8 expected/accepted? The context in which I am asking this question is
an application that exports various SQL rules for modeling purposes. T
17 matches
Mail list logo