471,316 Members | 1,304 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,316 software developers and data experts.

Problem displaying special characters

Hi,

I've got a problem with displaying texts with turkish characters.

There is a website administration system, which is developed using ASP
(VBScript) and ADO. This system is being used for inserting product
informations in to a ms-sql database.

There is another webbased application, which is developed using ASP.NET and
ADO.NET (C#). For this second application there is a separate ms-sql
database but the data on the first database is also being accessed and
displayed and that is exactly where my problem occures. The data, which was
written in to the database by the first application (ADO) can not be read by
the second application (ado.net) properly. Some of the turkish characters
are displayed as questionsmarks etc. The field at the database is NVARCHAR
(unicode).

Is there a way setting the encoding for a dataadapter before calling the
fill method? Or is there another workarround for this problem? Thanks in
advance.

Kivanc Toker
TUM Group IT Soluotions

Nov 19 '05 #1
4 3313
Does it mean that whatever the DataAdapter fills contains incorrect
characters or are they just displayed wrongly afterwards?
Best regards,

Henrik Dahl

"Kivanc Toker" <kt****@flashmail.com_NOSPAM> wrote in message
news:eG**************@TK2MSFTNGP10.phx.gbl...
Hi,

I've got a problem with displaying texts with turkish characters.

There is a website administration system, which is developed using ASP
(VBScript) and ADO. This system is being used for inserting product
informations in to a ms-sql database.

There is another webbased application, which is developed using ASP.NET and ADO.NET (C#). For this second application there is a separate ms-sql
database but the data on the first database is also being accessed and
displayed and that is exactly where my problem occures. The data, which was written in to the database by the first application (ADO) can not be read by the second application (ado.net) properly. Some of the turkish characters
are displayed as questionsmarks etc. The field at the database is NVARCHAR
(unicode).

Is there a way setting the encoding for a dataadapter before calling the
fill method? Or is there another workarround for this problem? Thanks in
advance.

Kivanc Toker
TUM Group IT Soluotions

Nov 19 '05 #2
Hi,

"Henrik Dahl" <He********@community.nospam> wrote in message
news:u%****************@TK2MSFTNGP09.phx.gbl...
Does it mean that whatever the DataAdapter fills contains incorrect
characters or are they just displayed wrongly afterwards?


When I make a simple search query in VS.NET, the information returned
contains invalid chars, which means the data inserted by ADO seems somehow
incorrect. But I can not say it for sure, because there is no turkish ms-sql
server version, which displays the texts correctly as we use them in our
language. But the first application (asp-ado-mssql server) displays the same
data correctly.

I know, what you think with "or are they just displayed wrongly afterwards".
I also use the required request, response and file encodings in web.config,
which is like:

<globalization

requestEncoding="ISO-8859-9"

responseEncoding="ISO-8859-9"

fileEncoding="ISO-8859-9"

culture="tr-TR"

uiCulture="tr-TR"

/>

Still need help...

Thank you..

Kivanc Toker

TUM Group IT Solutions
Nov 19 '05 #3
Got new informations about the problem.

http://forums.asp.net/518209/ShowPost.aspx

The most interesting part is :

"CAUSE:
The reason I found out was that each gb2312 character I store in MSSQL 2000,
it convert to unicode, splitting the double-byte characters into single
bytes, then converting each single-byte based on the codepage in
windows-1252 to the corresponding unicode equivalent.
Legacy ASP works, because everything is converted back from unicode back
into single-byte "char" (vs double-byte "char" in ASP.net), and all we have
to do is to set the response.charset=gb2312 to get it to work.
However in ASP.net, the WebForm does conversion base on the webform codepage
and webform charset, including the web.config globalization
responseEncoding, requestEncoding and fileEncoding. Hence you have to
manually set the webform codepage to windows-1252, but webform charset has
to be set to gb2312. During page_load, you have to type in
"response.charset=nothing" to display the data from MSSQL with no problem.
"

The problem is I didn't get the solution. I have the same problem with
turkish characters and I still need help.

Thanks in advance..

Kivanc Toker
Nov 19 '05 #4
What if you set the encoding to "UTF-8" instead of "ISO-8859-9"?

Best regards,

Henrik Dahl

"Kivanc Toker" <kt****@flashmail.com_NOSPAM> wrote in message
news:eK***************@TK2MSFTNGP15.phx.gbl...
Hi,

"Henrik Dahl" <He********@community.nospam> wrote in message
news:u%****************@TK2MSFTNGP09.phx.gbl...
Does it mean that whatever the DataAdapter fills contains incorrect
characters or are they just displayed wrongly afterwards?
When I make a simple search query in VS.NET, the information returned
contains invalid chars, which means the data inserted by ADO seems somehow
incorrect. But I can not say it for sure, because there is no turkish

ms-sql server version, which displays the texts correctly as we use them in our
language. But the first application (asp-ado-mssql server) displays the same data correctly.

I know, what you think with "or are they just displayed wrongly afterwards". I also use the required request, response and file encodings in web.config, which is like:

<globalization

requestEncoding="ISO-8859-9"

responseEncoding="ISO-8859-9"

fileEncoding="ISO-8859-9"

culture="tr-TR"

uiCulture="tr-TR"

/>

Still need help...

Thank you..

Kivanc Toker

TUM Group IT Solutions

Nov 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Mosher | last post: by
2 posts views Thread by David Scemama | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.