Problem with saving Chinese.

Hi.. I'm trying to save text into SQL 2000 database.

When user enter text in text box , the text save into variable , and show it in confirm page , after save the text to database, all the text turned into "??"

I try to view the data in SQL enterprise Manager / Web Matrix / ASP web page gridview , all of them showing the text fields in "??"

Then I try to add record which come with SQL 2000 enterprise Manager.After save the record , the chinese also turned into "??"

Is there something I need to set for database or server?

Is your datatype VARCHAR, TEXT or CHAR as the datatype on the table columns?

If VARCHAR change to NVARCHAR. If TEXT change to NTEXT. If CHAR change to NCHAR.

If you are using stored procedures (and you should be), you will to amend the parameter declaration on them.

You might want to change the collating sequence on your database to one more appropriate to Chinese (if collating sequence is meaningful for that language), but otherwise you should not need to change anything at the database level.

If this reply provides the anser to your question, please mark as such.

|||all the text are stored in varchar... I'll try to change it to nvarchar|||

yea... it works when I change all the text field type to nnvarchar..

Problem with reading in packet mode

Hi Ovidiu,
First of all, I would like to confirm my understanding of your issue. From
your description, I understand that when you call SQLSetStmtOption() before
SQLExecDirect() the performance is quite poor. If there is any
misunderstanding, please feel free to let me know.
Yes, as you know, the SQLSetStmtOption can be called before/after
SQLExecDirect. However, from ODBC 3.x SQLSetStmtOption is deprecated. It
has been replaced by SQLSetStmtAttr. So I suggest you try to use
SQLSetStmtAttr to see if performance goes better. Please check the
following link for more information.
http://msdn.microsoft.com/library/d...-us/odbc/htm/od
bcsqlsetstmtoption.asp
If that still doens't work, please feel free to reply to the post.
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."Hi Ovidiu,
What is the version of MDAC on your machine? Please try to upgrade to the
latest version MDAC 2.8 sp1 from the following link to see if it can
resolved the problem.
http://www.microsoft.com/downloads/...c895-efc2-4f8e-
a9e0-3a1afbd5922e&DisplayLang=en
Also I suggest you try to set to a larger packet size (e.g. 512).
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."|||Hi Kevin,
Yes, I have the latest MDAC version: MDAC 2.8 SP1 on Windows XP SP2.
It's true, the performance gets much better when we increase the packet size
(we already knew that), as follows:
- for packet size 512 I get aprox. 7 secs (compared to 49 secs)
- increasing packet size over 512 won't improve performance anymore
The bottom line is: even when using larger values for the packet size,
performance is still poor compared
to the case when SQLSetStmtOption is called after SQLExecDirect (7 secs vs.
1 sec). Why is that happening ?
So, increasing packet size is a good workaround but up to a point.
There is the following bussiness impact: the customers using our application
are asking questions about this (strange) behaviour. Is there any
Microsoft doc, release note, etc. that refers to it ?
Could this issue be escalated such that, at least, we could get an official
answer from Microsoft regarding this behaviour. This would prove at
least that we are not misusing the ODBC API in any way (this was our main
concern in the first place because, actually, the order of ODBC
calls causes this strange behaviour).
Your help is appreciated.
Regards,
Ovidiu
"Kevin Yu [MSFT]" <v-kevy@.online.microsoft.com> wrote in message
news:hYsGn42hFHA.944@.TK2MSFTNGXA01.phx.gbl...
> Hi Ovidiu,
> What is the version of MDAC on your machine? Please try to upgrade to the
> latest version MDAC 2.8 sp1 from the following link to see if it can
> resolved the problem.
> [url]http://www.microsoft.com/downloads/details.aspx?FamilyID=78cac895-efc2-4f8e-[/ur
l]
> a9e0-3a1afbd5922e&DisplayLang=en
> Also I suggest you try to set to a larger packet size (e.g. 512).
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>|||Hi Ovidiu,
Here, I suggest you try to use 4096 as the packet size to see if there is
any performance increment.. To get an official answer from Microsoft, you
need to contact PSS for professional support. You can find the contact
information from the following link:
http://support.microsoft.com/common...=gp;en-us;offer
prophone
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."|||Hi Kevin,
As I already specified in my previous reply, increasing packet size over a
certain limit won't improve performance anymore.
Thanks for your help. I will try to escalate this issue through PSS.
Regards,
Ovidiu
"Kevin Yu [MSFT]" <v-kevy@.online.microsoft.com> wrote in message
news:clVPgQDiFHA.3120@.TK2MSFTNGXA01.phx.gbl...
> Hi Ovidiu,
> Here, I suggest you try to use 4096 as the packet size to see if there is
> any performance increment.. To get an official answer from Microsoft, you
> need to contact PSS for professional support. You can find the contact
> information from the following link:
> [url]http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer[/ur
l]
> prophone
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>|||Hi Ovidiu,
Sorry that I could not provide further assistance on this issue. Good luck!
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."