I haven't worked much with Unicode, but either you didn't enter the Unicode
data properly with the UPDATE's SET clause, or the client app/tool with
which you do SELECT "downgrades" Unicode to "ordinary" character string.
I assume that you did enter the string with a preceding N, as in
SELECT N'This is a Unicode string'
MCDBA, MCSE, MCSD, MCT, SQL Server MVP
Cornerstone Sweden AB
Please reply to the newsgroup only, not by email.
> We attempted with nvarchar types but the problem is that SQL7 does a
> conversion which we do not want it to do. We were successfull in entering
> Polish characters (Code Page 1250 Windows Latin 2 (Central Europe)) with a
> SQL7 configured for CP1252 in the Query Analyzer, but when performing a
> Select on the Update we just did, we got our accented characters converted
> to the best-matching CP1252 characters. For example the character hex 9E
> (latin small letter Z with caron) became a plain lowercase Z...
> Thanks for some clarification, if possible.
> > Philip,
> > Can you use the Unicode datatypes?
> > (note that you still choose "sort order" for Unicode at server level,
> > "Unicode collation".)
> > --
> > Tibor Karaszi
> > MCDBA, MCSE, MCSD, MCT, SQL Server MVP
> > Cornerstone Sweden AB
> > Please reply to the newsgroup only, not by email.
> > > SQL7 requires you to make a choice as to which character set will be
> > in
> > > all databases it stores. Nice. But we need to store different
> > > one database. Seen the number of possible character sets, it is not
> > > likely that we will have SQL7 installed once per set. Is there a way
> > > combine it all in one installation?
> > > Thanks.