Problem of character set

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for MySQL
Post Reply
tomazyu
Posts: 2
Joined: Tue 16 May 2006 07:50
Location: Japan
Contact:

Problem of character set

Post by tomazyu » Wed 17 May 2006 05:19

I am Japanese. (Name=Otuki )
English cannot be spoken well.

It is such a state.

The content of the state of the problem is written.

Do it make like any, and is it ..character set of MySqlDirect.NET.. revokable?
It fails in writing without fail.(The character changes. )
It succeeds because of the command line.
The setting of the server doesn't have the problem.
It is of writing that this symptom goes out.

The character-code of UTF-8 cannot be used.

It is because a part of character cannot be properly treated.

I want to execute writing by using SJIS specified as much as possible by setting the server.

SJIS is assumed to be a client character set even if the connection information is seen and the notification has been received.

Please teach someone.

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Wed 17 May 2006 11:50

1.
It succeeds because of the command line.
What command line are you talking about?
2. Please send us you server configuration.
3.
The character-code of UTF-8 cannot be used.
Why?
4. Send us small test project if possible to reproduce the problem; it is
desirable to use 'test' schema objects, otherwise include definition of
your own database objects. Do not use third party components.

Guest

Post by Guest » Thu 18 May 2006 06:03

A,1
The Mysql client was used. Command line

UPDATE mailsysXXX SET Mailad = 'info@XXXX', Name = JapaneseChar, Comennt = JapaneseChar, Area = 'JapaneseChar', Indate = 'XXXXXXXX', Changeday = XXXXXXXX', delDay = XXXXXXXX, Flag = '' WHERE MailId = 1

Sentence of the above-mentioned description
The character can be normally preserved in the data base.
The client character set at this time is SJIS.

A,2(Setting of server)

Server Windows2003 Sp1
MysqlServer Ver 4.1.19

my.ini file
[mysql]
default-character-set=sjis
[client]
default-character-set=sjis
[mysqld]
port=3306
log-bin
basedir="C:/XXXXXXXXX/MySQL Server 4.1/"
datadir="C:/XXXXXXXXX/XXXXXXXXXX/Data/"
default-character-set=sjis
skip-character-set-client-handshake
default-storage-engine=INNODB
max_connections=100
query_cache_size=0
table_cache=256
tmp_table_size=5M
thread_cache_size=8

myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=8M
key_buffer_size=8M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=212K
language=japanese_sjis
innodb_additional_mem_pool_size=2M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=8M
innodb_log_file_size=12M
innodb_thread_concurrency=8

*There is no change when changing to CP932(WINDOWS SJIS).

Developer environment
Windows Xp Sp2
Visual Studio .NET 2003
Core Lab MySQLDirect .NET 3.20.9
Core Lab MySQLDirect .NET 3.20.9 Mobile

Message when connecting it (Direct True)

Client:
Version 4.1
Protocol:
Type Tcp
Server:
Version 4.1.19-community-nt-log
Client charset sjis
Database charset sjis

Message when connecting it (Direct False)

Client:
Version 5.0.21
Protocol:
Type Tcp
Server:
Version 4.1.19-community-nt-log
Client charset sjis
Database charset sjis


A,3
The reason has special circumstances to set a Japanese UTF-8 character.
The name of the problem"Double wave problem"

UniCode 0xff5e = S-JisCode 0x8148
The conversion is done.
The sign character in two bytes is converted as "?" in all two bytes. There is an exception.

A,4
This problem is in order of a Japanese environment. It is possible to reproduce it only with the client.
The sentence that parts that support a part of Japanese are lacked has been seen in "WINDOWS" of an English version on the support site of Microsoft.


My investigation result

The character set has been converted at the SLECT command. (It is an unknown in accuracy without. )

It is transmitted to the MYSQL server without converting the character string that exists in the parameter in the UPDATE command.
It is similar at the insert command.

Result of make log-bin option of server effective, and compare it by command sent from client with data of Core Lab DBMonitor

The value of the parameter seen with Core Lab DBMonitor is normal.
I think whether in the character set sent to the server different as a esult.


Is the result of make it like any obtained?

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Thu 18 May 2006 08:33

It is transmitted to the MYSQL server without converting the character string that exists in the parameter in the UPDATE command.
Should it be converted or not?
Try to use GetBytes method of MySqlDataReader class.

tomazyu
Posts: 2
Joined: Tue 16 May 2006 07:50
Location: Japan
Contact:

Post by tomazyu » Fri 19 May 2006 00:00

The problem was found.
It went by the method besides the instruction.

The character-code should not be converted.
This problem was a problem of happening because of unwilling conversion.

It is a problem of happening when the parameter is used because of the
MySqlCommand class.

SQL sentence with which Japanese mixed without specifying parameters for CommandType of the MySqlCommand class in the test was input and executed.
The result succeeded.

Can this problem be solved?
The meaning that buys this program disappears if it is not possible to solve it..........
:cry:

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Fri 19 May 2006 06:31

Make sure you have same encoding in your tables and in your .ini file.
Comment the string skip-character-set-client-handshake out.
Result of make log-bin option of server effective, and compare it by command sent from client with data of Core Lab DBMonitor
What did you conclude from this?

Guest

Post by Guest » Fri 19 May 2006 10:07

Alexey wrote:Make sure you have same encoding in your tables and in your .ini file.
There is no problem in the setting.

It seems to fail in the decipherment of the character string of the character in the use of SQL command sent to the server of the value of the parameter and generation.

It seems that the encoder at this time doesn't function normally though it seems that it stores in byte array when SQL command is generated, it is stored in the "String" character string, and it transmits.

Does this problem hit the specification of this product?
Or, does this problem have the ossibility to be corrected?

I think that this problem is a problem of the decipherment.

The maximum reason is decipherment in normality when assuming MySqlConnection1.Unicode=True.

Post Reply