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.
Problem of character set
1.
2. Please send us you server configuration.
3.
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.
What command line are you talking about?It succeeds because of the command line.
2. Please send us you server configuration.
3.
Why?The character-code of UTF-8 cannot be used.
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.
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?
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?
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..........
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..........
There is no problem in the setting.Alexey wrote:Make sure you have same encoding in your tables and in your .ini file.
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.