Converting string to unicode string in T-SQL

[yas...@gmail.com]

Hi,

We have stored proc name proc_test(str nvarchar(30)). So far this proc
has been invoked from a .NET application assuming that only English
character strings will be passed to it. The calls are like
proc_test('XYZ')
We now have a requirement for passing Chinese strings as well. Rather
than changing the calls throughout the application, we would like to
handle it in the stored procedure so that it treats the string as a
unicode string. Can we apply some function to the parameter to convert
it to unicode so that we don't have to call with an N prefixed to the
string?

Thanks,
Yash

[Uri Dimant]

Hi

> unicode string. Can we apply some function to the parameter to convert
> it to unicode so that we don't have to call with an N prefixed to the
> string?

Do you mean to get an INTEGER of the string , then you have UNICODE function
, see in the BOL.
What's wrong with calling with an N prefixed to the string?

<yas...@gmail.com> wrote in message
news:1174896401.9...@b75g2000hsg.googlegroups.com...

[Razvan Socol]

On Mar 26, 11:06 am, yas...@gmail.com wrote:
> [...]
> We now have a requirement for passing Chinese strings as well. [...]

> Can we apply some function to the parameter to convert it to unicode
> so that we don't have to call with an N prefixed to the string?

No, you can't. If you don't prefix it with N, then the chinese
characters are lost in the implicit conversion to varchar, so you
cannot get them back (unless the varchar has a DBCS collation, which
would be if you have the default server collation on a Chinese_*
collation, but I don't think that would be a good idea).

Razvan

[Mike C#]

<yas...@gmail.com> wrote in message
news:1174896401.9...@b75g2000hsg.googlegroups.com...

> Hi,
>
> We have stored proc name proc_test(str nvarchar(30)). So far this proc
> has been invoked from a .NET application assuming that only English
> character strings will be passed to it. The calls are like
> proc_test('XYZ')

You should go back and change your code to properly parameterize your
queries instead of concatenating the parameter values into strings,
VB5-style. Then you wouldn't have to worry about the N prefix. Or SQL
Injection.