So are you saying that both SQLS 7.0 and SQLS 2000 are surrogate aware and
will treat any surrogate value as ONE character with no defined sorting
characteristics, rather than two? I was left with the impression that SQLS
7.0 would treat them as two separate UCS-2 characters (at least one of which
would be with no defined sorting characteristics).
That would be excellent news if both versions handled them this way. :-)
----- Original Message -----
From: "Michael Kung" <firstname.lastname@example.org>
To: "Michael (michka) Kaplan" <email@example.com>; "Unicode List"
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 surrogate support statement does not provide any
> substantial context.
> -----Original Message-----
> From: Michael (michka) Kaplan [mailto:firstname.lastname@example.org]
> Sent: Monday, August 07, 2000 9:01 AM
> To: Unicode List
> Subject: Re: Encodings for SQL Databases
> From: <Marco.Cimarosti@icl.com>
> > 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 would expect W[ide], L[ong], or U[nicode]).
> This stands for "National" and comes from the ANSI-92 specification for
> (pardon the political incorrectness!).
> > I then tried saving the script with "Save As...". The choices
> > where "ANSI", "OEM (cp 437)", and "Unicode". Guess which
> > one I chose, and it saved the file in the UTF-16 (or is it UCS-2?)
> > format that is accepted by Notepad (find the file attached).
> Technically speaking, UCS-2 might be more accurate since SQL 7.0 does not
> have surrogate awareness. SQL Server 2000 has some surrogate awareness,
> the sorting of such characters is currently undefined, but I g uess you
> could claim it to be UTF-16 (although the docs do not do so).
> > About API's, I guess that:
> > 1) The N prefix for string literals should be used as well;
> > 2) The details of the UTF form used are handled by the API.
> Yes, plus. :-)
> Michael Kaplan
> Trigeminal Software, Inc.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:06 EDT