Non English Characters

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...Set your culture settings in your web.config file for the appropriate code
set that you use. This should solve the problem. You can also cast the
characters to ASCII by doing this (courtesy or Erland Sommerskog)

SELECT convert(varchar(6), N'IGDEM' COLLATE Cyrillic_General_CS_AS)

--
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.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

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...
>

|||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.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

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...
>

|||Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also :) However I cannot find a similar solution for
ASP.NET

Hilary Cotter wrote:

Quote:

Originally Posted by

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.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

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...

|||Hi,
Choosing ODBC provider rather than OLEDB, and turning of character
translation option solved my problem.

saygin@.gmail.com wrote:

Quote:

Originally Posted by

Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also :) However I cannot find a similar solution for
ASP.NET
>
>
>
>
Hilary Cotter wrote:

Quote:

Originally Posted by

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.comwrote in message
news:1159361639.289293.15470@.d34g2000cwd.googlegro ups.com...

Quote:

Originally Posted by

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...
>

Non English Characters

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...
Set your culture settings in your web.config file for the appropriate code
set that you use. This should solve the problem. You can also cast the
characters to ASCII by doing this (courtesy or Erland Sommerskog)
SELECT convert(varchar(6), N'IGDEM' COLLATE Cyrillic_General_CS_AS)
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...
>
|||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...
>
|||Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also However I cannot find a similar solution for
ASP.NET
Hilary Cotter wrote:[vbcol=seagreen]
> 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,
Choosing ODBC provider rather than OLEDB, and turning of character
translation option solved my problem.
saygin@.gmail.com wrote:[vbcol=seagreen]
> Hi, thanks for your interest.
> Changing culture setting did not help, also there is no chance to
> change data type of columns, they are varchar, not nvarchar.
> Character conversion of database libraries and using a DB-Library based
> API (in my previous example I'd chosen BDE) was Mr.Erland's
> recommendation also However I cannot find a similar solution for
> ASP.NET
>
>
> Hilary Cotter wrote:

Non English Characters

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...Set your culture settings in your web.config file for the appropriate code
set that you use. This should solve the problem. You can also cast the
characters to ASCII by doing this (courtesy or Erland Sommerskog)
SELECT convert(varchar(6), N'IGDEM' COLLATE Cyrillic_General_CS_AS)
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...
>|||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...
>|||Hi, thanks for your interest.
Changing culture setting did not help, also there is no chance to
change data type of columns, they are varchar, not nvarchar.
Character conversion of database libraries and using a DB-Library based
API (in my previous example I'd chosen BDE) was Mr.Erland's
recommendation also However I cannot find a similar solution for
ASP.NET
Hilary Cotter wrote:[vbcol=seagreen]
> A couple more thoughts are you storing the strings in nVarchar(20) data ty
pe
> 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,
Choosing ODBC provider rather than OLEDB, and turning of character
translation option solved my problem.
saygin@.gmail.com wrote:[vbcol=seagreen]
> Hi, thanks for your interest.
> Changing culture setting did not help, also there is no chance to
> change data type of columns, they are varchar, not nvarchar.
> Character conversion of database libraries and using a DB-Library based
> API (in my previous example I'd chosen BDE) was Mr.Erland's
> recommendation also However I cannot find a similar solution for
> ASP.NET
>
>
> Hilary Cotter wrote:

no such interface supported virus

I'm running an access 2000 front end with a slq server 2000 back end on a lo
cal network. All of the sudden one workstation couldn't connect to the serv
er. So after trying several things I think I've came to the correct conclus
ion. I believe that the ma
chine was infected by a virus that was missed by two different scanners. I
think its a hijack virus that takes control of sql when its trying to connec
t to the server using the server name. Its very odd and isn't detected by s
canners. A temp. fix is to
just use the ip of the server to connect and then it works. Also if I try a
nd ping the server by name it doesn't get a return however if I use the elon
gated full name of the server with domain its fine. Any ideas suggestions c
lues?Is the server running a Personal Firewall?
Are you connecting via TCP or Named Pipes?
What are you using for Name Resolution of the server?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

No such interface supported

I receive "No such interface supported" in SQL Server 2005, when:

1. on server, from my desktop client: attempting to create a maintenance plan within Management Studio without the wizard (with the wizard, works fine)

2. trying to copy, using SMO, an entire database from the server, to my local machine, from again, my desktop client.

Any thoughts?

No solution, I'm afraid, but this is happening to me, too.

Did you find a solution yourself by any chance?

|||Unfortunately, no |||Verified by me too.|||A good candidate to keepup the details under http://connect.microsoft.com/ and might check someone already reported. I presume you have applied SP1 on that SQL 2005.|||it's been a while, several installations ago, several months now, since I've had this issue, sicne applying SP1 I believe ...

No such interface supported

I receive "No such interface supported" in SQL Server 2005, when:

1. on server, from my desktop client: attempting to create a maintenance plan within Management Studio without the wizard (with the wizard, works fine)

2. trying to copy, using SMO, an entire database from the server, to my local machine, from again, my desktop client.

Any thoughts?

No solution, I'm afraid, but this is happening to me, too.

Did you find a solution yourself by any chance?

|||Unfortunately, no |||Verified by me too.|||A good candidate to keepup the details under http://connect.microsoft.com/ and might check someone already reported. I presume you have applied SP1 on that SQL 2005.|||it's been a while, several installations ago, several months now, since I've had this issue, sicne applying SP1 I believe ...

No such interface supported

I receive "No such interface supported" in SQL Server 2005, when:

1. on server, from my desktop client: attempting to create a maintenance plan within Management Studio without the wizard (with the wizard, works fine)

2. trying to copy, using SMO, an entire database from the server, to my local machine, from again, my desktop client.

Any thoughts?

No solution, I'm afraid, but this is happening to me, too.

Did you find a solution yourself by any chance?

|||Unfortunately, no |||Verified by me too.|||A good candidate to keepup the details under http://connect.microsoft.com/ and might check someone already reported. I presume you have applied SP1 on that SQL 2005.|||it's been a while, several installations ago, several months now, since I've had this issue, sicne applying SP1 I believe ...

No such interface supported

I receive "No such interface supported" in SQL Server 2005, when:

1. on server, from my desktop client: attempting to create a maintenance plan within Management Studio without the wizard (with the wizard, works fine)

2. trying to copy, using SMO, an entire database from the server, to my local machine, from again, my desktop client.

Any thoughts?

No solution, I'm afraid, but this is happening to me, too.

Did you find a solution yourself by any chance?

|||Unfortunately, no |||Verified by me too.|||A good candidate to keepup the details under http://connect.microsoft.com/ and might check someone already reported. I presume you have applied SP1 on that SQL 2005.|||it's been a while, several installations ago, several months now, since I've had this issue, sicne applying SP1 I believe ...