mysql#1366错误是在mysql5.0.2以上版本才出现的，不管是编码还是字段不符合规则，就通不过mysql严格的数据检查，#1366错误就是这样出现的。当然如果你有修改my.ini的权限，通常#1366是很好解决掉的。只要把my.ini里的sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"这句话修改成sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"就可以了。虚拟主机通常没有这种修改权限，如果是编码问题导致的#1366错误，那么请看我下面的介绍吧。或许对你有些帮助。
本人用XOOPS架的网站(www.visteel.com)已经搬过几次家了，由于每次搬家都没有做好数据库的编码整理，随着数据表的增多，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首发，转载请注明文章来源www.visteel.com