A couple more thoughts are you storing the strings in nVarchar(20) data type
columns. Also if you use Erland's method you will loose the Turkish
characters if you store them using his technique but the searching should
work.

--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.

This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.

Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com



<saygin@gmail.com> wrote in message
news:1159361639.289293.15470@d34g2000cwd.googlegro ups.com...
> Hi,
> We are developing a small web interface to a local ERP software, which
> uses SQL Server 2000 as database. The database uses SQL_Latin1_CP1
> collation, and the fields are varchar (not nvarchar), however, the main
> program inserts and reads non-English (Turkish) characters into these
> columns. However, when we connect to database with ADO.NET, these
> characters are not read correctly. (The situation is same when I check
> tables with Enterprise Manager and Query Analyzer)
>
> In a past situation (which was about a Win32 application), I have heard
> about character conversion behaviour of ADO (and many other DB
> libraries) and solved that problem using BDE instead of ADO, so that
> the connection is made via DB-Library instead of OLEDB.
>
> But this way cannot be applied to my ASP.NET situation, and there is NO
> way to change database collation. Must I use a ADO.NET property, or use
> another provider, or maybe another library? Any advices? Thanks...
>