如何实战解决mysql#1366错误.pdf

如何实战解决 mysql#1366 错误 mysql#1366 错误是在mysql5.0.2 以上版本才出现的，不管是编码还是字 段不符合规则，就通不过mysql 严格的数据检查，#1366 错误就是这样出现 的。当然如果你有修改my.ini 的权限，通常#1366 是很好解决掉的。只要把 my.ini 里的sql- mode=STRI*ANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION这句 话修改成sql-mode=NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION就可以 了。虚拟主机通常没有这种修改权限，如果是编码问题导致的#1366 错误，那 么请看我下面的介绍吧。或许对你有些帮助。 本人用XOOPS 架的网站()已经搬过几次家了，由于每次搬家都没有做好数 据库的编码整理，随着数据表的增多，gb2312、gbk、utf8、latin1 等字符整 理方式都混在了一起。而虚拟主机的mysql 版本已经是5.1.36 了，终于在做数 据更新的时候，让人头疼的#1366 错误出现了。好，还是说解决的办法吧。首 先我网站数据库是gbk 的，那么就把里面的全部数据表重新整理一下吧。 可是已经存储了数据的表个别是不能再简单通过phpmyadmin 等管理工具处 理的了。这个时候你需要两个工具，一个是mysqlodbc 下载并按装mysql- connector-odbc-5.1.8-win32 一个是navicatformysql。 第一步：控制面板-管理工具-数据源。在本地Windows 下建立个 mysqlODBC 数据源，假设命名成visteel 第二步：打开NavicatforMySQL，单击“Connection”按钮设置连接。 第三步：连接上数据库服务器后右键单击数据库服务器选择 “NewDatabase…”新建一个数据库。记得“Characterset”选定gbk; 第四步：选中要转换的表，将它们拖到新进的数据库中，在弹出的选项窗 中选择“Copyhere(Structureonly)”,将数据表的结构复制到新数据库中; 第五步：在新建的数据库中选中刚导过来的所有的表，右键选择 “DumpSQLFile”导出成sql 文件; 第六步：用文本编辑器打开刚导出的sql 文件，将里面的 DEFAULTCHARSET=后面不论是什么，全部替换成DEFAULTCHARSET=gbk，保存修 改过的sql 文件。 第七步：全选新建的数据库中的所有表，单击“DeleteTable”删除。然后 右键单击新建的数据库选择“ExecuteSqlFile…”,找到并双击改过的sql 文 件，将改过的sql 文件重新导回数据库中。 第八步：选中新建的数据库然后再点击：“ImportWizard”按钮。选择 ODBC，点下一步。 第九步：点“ImportFrom:”右边的“…”按钮，然后在“数据连接”属性 窗口选择“连接”这一页，在 “1、指定数据源”中选择在第一步中建立的数据 源“visteel”;确定后返回“step2of8”窗口，选中需要转换的表，或者点击 “selectall”按钮选择整个数据库的所有的表。连续点击三次“next”按钮后 来到“Step7of8”对话框。 第十步：选择“Copy： deleteallrecordsindestination,repopulatefromthesource”:再单击” next”来到“step8of8”对话框。 第十一步：单击按钮“start”开始转换，直到出现信息 “[Msg][lmp]Finished-Successfully”。 到此，数据库完美完成了GBK 的整理。编辑XOOPS 根目录下的 mainfile.php 文件，将define(XOOPS_DB_CHARSET,gb2312)修改成 define(XOOPS_DB_CHARSET,gbk); 将本地数据库导出上传到虚拟主机进行测试，至此，mysql#1366 错误全部 消失掉了。而且生僻汉字也不再是用??显示了。 Admin5 首发，转载请注明文章来源 文章来源于：/article-23656-1.html