N' prefix required or not?

Need to provide international support for the product. Use
SqlServer 2000 for repository; DataDirect JDBC driver and
Java code for the application.
Using nvarchar datatypes for columns. Data entry/retrieval
will be through Java code. When send SQL commands through
Java/JDBC; do we need to prefix the constants with the N'
prefix example - INSERT INTO abc VALUES (N'xyz') or will
INSERT INTO abc VALUES ('xyz') store the data in unicode.
If the datatype supports unicode chars do we still need to
use the N'prefix? Also assuming data is stored in unicode;
when using in where clause while selecting will we have to
use SELECT * from abc where f1 =N'xyx' for it to be
retrieved? FYI, All database access is through Java/JDBC
which both claim to provide full international/unicode
support.
Thanks,If you are sending in hard-coded strings, then you will need to prefix them
with N to indicate that the string is Unicode. Otherwise, unicode strings
will be stored as a series of junk characters in SQL Server.
--
HTH,
SriSamp
Please reply to the whole group only!
http://www32.brinkster.com/srisamp
"AB" <anonymous@.discussions.microsoft.com> wrote in message
news:900901c3e9f5$a1fc1f20$a501280a@.phx.gbl...
> Need to provide international support for the product. Use
> SqlServer 2000 for repository; DataDirect JDBC driver and
> Java code for the application.
> Using nvarchar datatypes for columns. Data entry/retrieval
> will be through Java code. When send SQL commands through
> Java/JDBC; do we need to prefix the constants with the N'
> prefix example - INSERT INTO abc VALUES (N'xyz') or will
> INSERT INTO abc VALUES ('xyz') store the data in unicode.
> If the datatype supports unicode chars do we still need to
> use the N'prefix? Also assuming data is stored in unicode;
> when using in where clause while selecting will we have to
> use SELECT * from abc where f1 =N'xyx' for it to be
> retrieved? FYI, All database access is through Java/JDBC
> which both claim to provide full international/unicode
> support.
> Thanks,