UTF-8 support: What about N'xxx' string literals?

Hi all,

Concerning UTF-8 / UNICODE support, I was wondering about the usage of N'xxx'
string literals in SQL statements (in ODBC or tsql commands)...

Actually if you want to specify a "UNICODE" (i.e. UCS-2) string in SQL Server,
you must prefix the string with a N :

create table tab1 ( k int, c nchar(10), nvarchar(10) )
go
insert into tab1 values (1, 'abc王鴻', 'abc王鴻傑王鴻傑' )
go
insert into tab1 values (2, N'abc王鴻', N'abc王鴻傑王鴻傑' )
go
select * from tab1
go

Otherwise, non-prefixed strings are converted by SQL Server to the default
code page of the database... (following docs).

Actually SQL Server docs talk about "Server side" programming, where strings
should use N prefix for UNICODE (UCS-2), but what about the clients then?

From my understanding, if I want to use UTF-8 encoded strings in my SQL stmts,
(defining my FreeTDS client charset as UTF-8 and forcing FreeTDS to convert from
UTF-8 to UCS-2 for TDS exchanges), I need always to specify N prefix to avoid
the server-side conversion to the database charset defined by the collation.

Since FreeTDS converts from any client charset to/from UCS-2 for TDS exchanges,
the final string literal will be encoded in UCS-2 and so the client is seen as
a UCS-2 client from the server... right?

So should not ALL FreeTDS application use the N prefix for string literals,
even if the encoding is for example ISO-8859-1?

Maybe some words about this could be added to:

http://www.freetds.org/userguide/localization.htm

Thanks!
Seb
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds