[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.sqlserver.programming

Select statement problem

kivanctoker

3/20/2007 8:15:00 AM

Hi,

My website is hosted by a company which is located in Canada. All
database servers and databases are in SQL_Latin1_General_CP1_CI_AS
collation and I am unable to change the default settings of the server
because of security issues.

I can intsert, update, delete the entries in my database without a
problem but when it comes to search a record including turkish chars I
couldn't find way to get the right resultset from the query.

Because of the collation all turkish chars are being inserted
differently in to the database. For example i (i without a dot) is
being inserted as a ý and s as a þ.

I'm triggering the search on a web form after entering a key to a
textbox. If the key contains one of the turkish chars above, the
search is not returning the right results.

For example:

The database contains a record with a name field, which has the value
"ayakkabý"
The search statement is :

SELECT * FROM Entities WHERE [Name] LIKE '%' + @name + '%'

This a part of the stored procedure and the variable @name is already
declared above this statement.

I'm inserting the value of the text box into this parameter and
executing the stored procedure but because of the different values
(ayakkabi <> ayakkabý) the search is not working as expected.

Is there any way to work arround this issue, other than changing the
default collation for the database?

Thanks in advance.

Regards,
Kivanc Toker

3 Answers

Razvan Socol

3/20/2007 9:55:00 AM

0

Hello, Kivan

Make sure that you use nvarchar instead of varchar (as the data type
for the columns, variables and parameters) and specify all strings
prefixed with N, for example N'some string', to use Unicode
characters.

Razvan

masri999

3/20/2007 3:27:00 PM

0

On Mar 20, 1:14 pm, kivancto...@gmail.com wrote:
> Hi,
>
> My website is hosted by a company which is located in Canada. All
> database servers and databases are in SQL_Latin1_General_CP1_CI_AS
> collation and I am unable to change the default settings of the server
> because of security issues.
>
> I can intsert, update, delete the entries in my database without a
> problem but when it comes to search a record including turkish chars I
> couldn't find way to get the right resultset from the query.
>
> Because of the collation all turkish chars are being inserted
> differently in to the database. For example i (i without a dot) is
> being inserted as a ý and s as a þ.
>
> I'm triggering the search on a web form after entering a key to a
> textbox. If the key contains one of the turkish chars above, the
> search is not returning the right results.
>
> For example:
>
> The database contains a record with a name field, which has the value
> "ayakkabý"
> The search statement is :
>
> SELECT * FROM Entities WHERE [Name] LIKE '%' + @name + '%'
>
> This a part of the stored procedure and the variable @name is already
> declared above this statement.
>
> I'm inserting the value of the text box into this parameter and
> executing the stored procedure but because of the different values
> (ayakkabi <> ayakkabý) the search is not working as expected.
>
> Is there any way to work arround this issue, other than changing the
> default collation for the database?
>
> Thanks in advance.
>
> Regards,
> Kivanc Toker

Try

SELECT * FROM Entities WHERE [Name] COLLATE 'collation name' LIKE
'%' + @name + '%'

Hugo Kornelis

3/20/2007 6:30:00 PM

0

On 20 Mar 2007 01:14:30 -0700, kivanctoker@gmail.com wrote:

(snip)
>Is there any way to work arround this issue, other than changing the
>default collation for the database?

Hi Kivanc,

In addition to the replies posted by Razvan and M A, you can also
specify a collation for a column when you create the table:

CREATE TABLE Test
(Col1 nchar(1) COLLATE xxxx,
Col2 nvarchar(100) COLLATE yyyy);

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hug...