PROBLEM WITH BACKUP in MySqlDump

PROBLEM WITH BACKUP in MySqlDump

Postby pvl » Thu 02 Feb 2006 14:29

Dear CoreLab,
I have some problem when use backup in MySqlDump.
Some RUSSIAN letters is not correct in DumpText property after run Backup method of MySqlDump. For example:
This are data in table m_firms:

FirmID FirmName FirmNote
1 Фирма 1
2 Фирма 2
3 Предприятие такое-то 1
4 Тестовое предприятие
6 ООО МММ
7 ЗАО какоето null
8 The LTD Firm null
9 ЧП Васильев null
10 ЧП Такое то null
11 ДП такое сякое null
12 Test Firm Name 1 null
13 Иванов null
14 Петров null
15 Сидоров null
16 Тестирование null
17 Тест2 null
18 Проверка null


After run Backup method I have in DumpText property the folloing value:

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

DROP TABLE IF EXISTS m_firms;

CREATE TABLE `m_firms` (
`FirmID` int(11) unsigned NOT NULL auto_increment,
`FirmName` varchar(80) NOT NULL,
`FirmNote` varchar(150) default NULL,
PRIMARY KEY (`FirmID`),
UNIQUE KEY `FirmName` (`FirmName`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251 COMMENT='InnoDB free: 10240 kB';

/*!40000 ALTER TABLE m_firms DISABLE KEYS */;
LOCK TABLES m_firms WRITE;
INSERT INTO m_firms VALUES (1, 'Фирма 1', '');
INSERT INTO m_firms VALUES (2, 'Фирма 2', '');
INSERT INTO m_firms VALUES (3, 'Предприятие такое-то 1', '');
INSERT INTO m_firms VALUES (4, '\"5AB>2>5 ?@54?@8OB85', '');
INSERT INTO m_firms VALUES (6, 'ООО МММ', '');
INSERT INTO m_firms VALUES (7, 'ЗАО какоето', NULL);
INSERT INTO m_firms VALUES (8, 'The LTD Firm', NULL);
INSERT INTO m_firms VALUES (9, '\ 0A8;L52', NULL);
INSERT INTO m_firms VALUES (10, '\ \"0:>5 B>', NULL);
INSERT INTO m_firms VALUES (11, 'ДП такое сякое', NULL);
INSERT INTO m_firms VALUES (12, 'Test Firm Name 1', NULL);
INSERT INTO m_firms VALUES (13, 'Иванов', NULL);
INSERT INTO m_firms VALUES (14, 'Петров', NULL);
INSERT INTO m_firms VALUES (15, 'Сидоров', NULL);
INSERT INTO m_firms VALUES (16, '\"5AB8@>20=85', NULL);
INSERT INTO m_firms VALUES (17, '\"5AB2 ', NULL);
INSERT INTO m_firms VALUES (18, 'Проверка', NULL);
UNLOCK TABLES;
/*!40000 ALTER TABLE m_firms ENABLE KEYS */;

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;


I try to dump this table with EMS SQL Manager 2005 For MySQL and
it work good.

Please help.
pvl
 
Posts: 12
Joined: Fri 14 Oct 2005 07:53

Postby Serious » Thu 02 Feb 2006 15:03

We have fixed this problem for the MySQLDirect .NET.
Look forward for the next build.

Check if you can use MySqlConnection.Unicode = false till we'll release new build. Refer to this property documentation for additional information.
Serious
 

Postby pvl » Thu 02 Feb 2006 15:28

Serious wrote:We have fixed this problem for the MySQLDirect .NET.
Look forward for the next build.

Check if you can use MySqlConnection.Unicode = false till we'll release new build. Refer to this property documentation for additional information.


if I set MySqlConnection.Unicode = false I have this result:

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

DROP TABLE IF EXISTS m_firms;

CREATE TABLE `m_firms` (
`FirmID` int(11) unsigned NOT NULL auto_increment,
`FirmName` varchar(80) NOT NULL,
`FirmNote` varchar(150) default NULL,
PRIMARY KEY (`FirmID`),
UNIQUE KEY `FirmName` (`FirmName`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251 COMMENT='InnoDB free: 10240 kB';

/*!40000 ALTER TABLE m_firms DISABLE KEYS */;
LOCK TABLES m_firms WRITE;
INSERT INTO m_firms VALUES (1, '????? 1', '');
INSERT INTO m_firms VALUES (2, '????? 2', '');
INSERT INTO m_firms VALUES (3, '??????????? ?????-?? 1', '');
INSERT INTO m_firms VALUES (4, '???????? ???????????', '');
INSERT INTO m_firms VALUES (6, '??? ???', '');
INSERT INTO m_firms VALUES (7, '??? ???????', NULL);
INSERT INTO m_firms VALUES (8, 'The LTD Firm', NULL);
INSERT INTO m_firms VALUES (9, '?? ????????', NULL);
INSERT INTO m_firms VALUES (10, '?? ????? ??', NULL);
INSERT INTO m_firms VALUES (11, '?? ????? ?????', NULL);
INSERT INTO m_firms VALUES (12, 'Test Firm Name 1', NULL);
INSERT INTO m_firms VALUES (13, '??????', NULL);
INSERT INTO m_firms VALUES (14, '??????', NULL);
INSERT INTO m_firms VALUES (15, '???????', NULL);
INSERT INTO m_firms VALUES (16, '????????????', NULL);
INSERT INTO m_firms VALUES (17, '????2 ', NULL);
INSERT INTO m_firms VALUES (18, '????????', NULL);
UNLOCK TABLES;
/*!40000 ALTER TABLE m_firms ENABLE KEYS */;

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;

Could you please fix this problem at your earliest convenience.
Thank you.
Pavel.
pvl
 
Posts: 12
Joined: Fri 14 Oct 2005 07:53

Postby Serious » Fri 03 Feb 2006 14:15

I've tested MySqlDump component with MySqlConnection.Unicode=false property and russian encoding. There were no problems in my test. Here is the sample code and output
Code: Select all
      MySqlConnection connection = new MySqlConnection("host=localhost;user id=root;password=root;port=3306;database=test;");
      connection.Open();

      MySqlCommand command = new MySqlCommand("set names cp1251", connection);
      command.ExecuteNonQuery();

      MySqlDump dump = new MySqlDump();
      dump.Connection = connection;
      dump.Tables = "cp866_test";
      dump.Backup();

      using (System.IO.StreamWriter sw = new StreamWriter(@"d:\dump.txt")) {
        sw.WriteLine(Encoding.Default.EncodingName);
        sw.WriteLine("------------------------");
        sw.Write(dump.DumpText);
      }
Code: Select all
Cyrillic (Windows)
------------------------
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

CREATE TABLE `cp866_test` (
  `id` int(11) NOT NULL auto_increment,
  `f_varchar` varchar(45) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=cp866;

INSERT INTO cp866_test VALUES (7, 'ЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮЁ');
INSERT INTO cp866_test VALUES (8, 'йцукенгшщзхъфывапролджэячсмитьбюё');

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
Serious
 

Postby pvl » Fri 03 Feb 2006 15:09

But I have that result after run your example (UNICODE=FALSE) :

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

DROP TABLE IF EXISTS cp866_test;

CREATE TABLE `cp866_test` (
`id` int(11) NOT NULL auto_increment,
`f_varchar` varchar(45) default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=cp866;

/*!40000 ALTER TABLE cp866_test DISABLE KEYS */;
LOCK TABLES cp866_test WRITE;
INSERT INTO cp866_test VALUES (7, '&#()%*$+ -/\!\",.');
INSERT INTO cp866_test VALUES (8, 'йцукенгшщзхъфывапролджэячсмитьбюё');
UNLOCK TABLES;
/*!40000 ALTER TABLE cp866_test ENABLE KEYS */;

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
pvl
 
Posts: 12
Joined: Fri 14 Oct 2005 07:53

Postby pvl » Fri 03 Feb 2006 15:13

I have mysql-5.0.18 build.
pvl
 
Posts: 12
Joined: Fri 14 Oct 2005 07:53

Postby Serious » Fri 03 Feb 2006 15:23

At first check if data in the database is valid.
Second, check if your server config file includes following option:
Code: Select all
[mysqld]
...
default-character-set=cp1251
I use MySql Server 5.0.18.
Serious
 

Postby pvl » Fri 03 Feb 2006 15:56

Yes, data in database is valid (i use EMS SQL Manager 2005 For MySQL for view db and work with it)

[mysql]

default-character-set=cp1251

is present in my.ini file

P.S. I get the same result on 3 different testing computers/
pvl
 
Posts: 12
Joined: Fri 14 Oct 2005 07:53

Postby Serious » Mon 06 Feb 2006 08:46

[mysql] section in my.ini configures MySQL command line client, not server. Please change [mysqld] section which corresponds to server configuration.
Serious
 

Postby pvl » Mon 06 Feb 2006 09:55

Serious wrote:[mysql] section in my.ini configures MySQL command line client, not server. Please change [mysqld] section which corresponds to server configuration.


The part of my.ini ([mysqld]):

# SERVER SECTION
# ----------------------------------------------------------------------
#
# The following options will be read by the MySQL Server. Make sure that
# you have installed the server correctly (see above) so it reads this
# file.
#
[mysqld]

# The TCP/IP Port the MySQL Server will listen on
port=3306


#Path to installation directory. All paths are usually resolved relative to this.
basedir="C:/MySQL/MySQL Server 5.0/"

#Path to the database root
datadir="C:/MySQL/MySQL Server 5.0/Data/"

# The default character set that will be used when a new schema or table is
# created and no character set is defined
default-character-set=cp1251

# The default storage engine that will be used when create new tables when
default-storage-engine=INNODB

# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

# The maximum amount of concurrent sessions the MySQL server will
# allow. One of these connections will be reserved for a user with
# SUPER privileges to allow the administrator to login even if the
# connection limit has been reached.
max_connections=100

# Query cache is used to cache SELECT results and later return them
# without actual executing the same query once again. Having the query
# cache enabled may result in significant speed improvements, if your
# have a lot of identical queries and rarely changing tables. See the
# "Qcache_lowmem_prunes" status variable to check if the current value
# is high enough for your load.
# Note: In case your tables change very often or if your queries are
# textually different every time, the query cache may result in a
# slowdown instead of a performance improvement.
query_cache_size=0

# The number of open tables for all threads. Increasing this value
# increases the number of file descriptors that mysqld requires.
# Therefore you have to make sure to set the amount of open files
# allowed to at least 4096 in the variable "open-files-limit" in
# section [mysqld_safe]
table_cache=256

# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
tmp_table_size=5M


# How many threads we should keep in a cache for reuse. When a client
# disconnects, the client's threads are put in the cache if there aren't
# more than thread_cache_size threads from before. This greatly reduces
# the amount of thread creations needed if you have a lot of new
# connections. (Normally this doesn't give a notable performance
# improvement if you have a good thread implementation.)
thread_cache_size=8
pvl
 
Posts: 12
Joined: Fri 14 Oct 2005 07:53

Postby Serious » Mon 06 Feb 2006 10:52

You have to wait for next build to work with MySqlDump component when dumping tables with russian encoding.
We cannot specify date of the build.
Serious
 

Postby pvl » Wed 08 Feb 2006 09:25

Besides, backup/restore of BLOB field don't work correct (I have images in blob field)
pvl
 
Posts: 12
Joined: Fri 14 Oct 2005 07:53

Postby Serious » Wed 08 Feb 2006 14:09

This problem relates to previous one.
Serious
 


Return to dotConnect for MySQL