DRUPAL_4.6.6的mysql数据库由4.0升级4.1操作过程记录

April 4th, 2006

DRUPAL_4.6.6的mysql数据库由4.0升级4.1操作过程记录

Posted by kunstao in Drupal教程

大概是要转移DRUPAL了。
数据库移动后之后很多错误和乱码，有个MANBO的移动解决办法，参考一下，理论上是应该一样的。见这
具体DRUPAL要怎么改一下数据库还不知道，查找ing….

Specified key was too long; max key length is 1000 bytes: ）

CREATE TABLE `mos_core_acl_aro` (
`aro_id` int(11) NOT NULL auto_increment,
`section_value` varchar(240) NOT NULL default ‘0′,
`value` varchar(240) NOT NULL default ”,
。。。
PRIMARY KEY (`aro_id`),
– –UNIQUE KEY `section_value_value_aro` (`section_value`,`value`),
– –UNIQUE KEY `mos_gacl_section_value_value_aro` (`section_value`,`value`),

这句如何替代呢？
是4.6+mysql，你可以试一下database.mysql.inc中的db_connect()函数的mysql_select_db一行之后，return之前加入这样一行：

mysql_query(”SET NAMES ‘utf8′”, $connection);
mysql_query(”SET CHARACTER SET utf8″, $connection);

可以避免与mysql数据库字符集不一致的问题。

ALTER DATABASE database CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE {each table name} CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

有人说如此也可以

the answer.. delete the part of the line that goes

ENGINE=MyISAM DEFAULT CHARSET=latin1
AUTO_INCREMENT=1 for each table

还有个反升级

I had an issue migrating form 4.1 to 4.0 and had a font problem too. I ended up using:
$ mysqldump -u {username} -p –quote-names –opt –compatible mysql40 {databasename} >output.sql

I then scp’ed output.sql over to the new ISP (which was running 4.0), created a new database, imported the file with:

$ mysql -u {username} -p {databasename} <~/output.sql

这个办法好像很不错，我还没成功。导入的时候总报告表头错误

将导出来的 sql 文件中的 character set 和 collate 分别都设成 utf8 和 utf8_general_ci ，同时把数据库的 collation 也改成 utf8_general_ci ，然后重新导到 MySQL 5.0 ，再把之前修改过的 select_lang.lib.php 改回原样，这样 phpMyAdmin 中的乱码问题就彻底解决了。

避免出现这个问题，只需在导入数据之前，先将数据库的 collation 设为 utf8_general_ci。

PHP 连接 MySQL 5.0 数据库后，最好先执行以下几句，以免因为 collation 问题而出现各种难以预见的错误：

1. SET NAMES ‘utf8′
2. SET CHARACTER SET ‘utf8′
3. SET CHARACTER_SET_CLIENT = ‘utf8′
4. SET COLLATION_CONNECTION=’utf8_general_ci’
5. SET CHARACTER_SET_RESULTS = ‘utf8′
6. SET CHARACTER_SET_SERVER = ‘utf8′

Updated 2006-3-13

Marco Fang 在回复里提出了另外一个很好的解决办法，我把它也贴到这里来了，谢谢！ ^_^

1. mysqldump –default-character-set=latin1 foobar > foobar.sql 这样就会得出一个编码正确的档

2.更改foobar.sql内中的 latin1 字段为 utf8 (replace all latin1 -> utf8)

3.转换此 sql 档为 unicode(方便直接转换为正确的utf8编码)

4.在 phpMyAdmin 中导入 foobar.sql，或是在 SQL 直接贴上 foobar.sql 的内容

转一篇类似文章

问题背景：老朱的新闻系统要更新，需要将原系统中的新闻数据导到新系统中来。原系统使用Fedora 3，新系统使用Debian。原系统中的数据库是自己编译安装的。新系统中的数据库是使用Debian系统中的发行包安装的。而且因为新系统与论坛共用一台服务器，论坛要求用gbk编码，因此，我在新系统的mysql配置文件中已经使用：init-connect=’SET NAMES gbk’进行了编码的强制初始化。

问题出现：当从旧系统中，使用mysqldump导出新闻数据，并拷到新系统中后，使用MySQL导入，结果里面的所有中文都是乱码。通过 phpmyadmin进行查看也是这样。将数据文件下载到本地windows机器上使用utf-8能够打开。通过phpmyadmin将数据文件中的记录添加到数据库中，中文显示正常。

问题的解决：

我首先想到了是不是因为终端字符集的问题。因为我终端默认字符集使用的是gbk，而数据文件的编码字符集是utf-8，是这个问题吗？通过export将终端的字符集改为utf-8:export LC_ALL=zh_ZN.UTF-8;export LANGUAGE=zh_ZN.UTF-8。然后使用mysql导入数据文件。问题依旧！中文显示的还是问号(?)。

难道是因为数据文件不应该使用utf-8的字符集编码？于是我将数据文件默认编码改为gbk(用iconv -f utf-8 -t gbk file.sql将文件编码改为gbk竟然还出错！iconv: illegal input sequence at position 3745。看来是因为乱造成的。终端不可以改变编码，我在windows下打开后另存总可以了吧。)再次导入，还是问号！

于是我考虑一个问题：为什么通过phpmyadmin可以导入数据，而通过终端则不可以呢？phpmyadmin使用的是utf-8编码，终端也是使用的 utf-8编码。为什么不可以呢？忽然，我想到一个问题，mysql初始化配置中的set names gbk.使用phpmyadmin，相当于utf-8–>set names gbk—>数据库中的记录(la1tin)。查询时：数据库中的记录(la1tin1)—>set names gbk—>utf-8。而对于终端这种方式，导入时是：utf-8—>数据库中的记录(latin1)，而查询时是:数据库中的记录 (latin1)—>set names gbk—>utf-8。查询时，两种相同。区别只在于使用phpmyadmin的时候，相当于多了一个set names gbk的操作！是因为这样吗？在数据文件的最开头，插入一行：set names gbk;然后将终端默认字符集改为utf-8(不知是否必需?)，导入数据文件。一切正常！

相关文章：