Hilary Cotter wrote:
> 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.googlegroups.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...
> >