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架的网站已经搬过几次家了，由 于每次搬家都没有做好数据库的编码整理，随着数据表的增多，gb2312、gbk、utf8、latin1等字符整理方式都混在了一起。而虚拟主机的 mysql版本已经是5.1.36了，终于在做数据更新的时候，让人头疼的#1366错误出现了。好，还是说解决的办法吧。首先我网站数据库是gbk的， 那么就把里面的全部数据表重新整理一下吧。

可是已经存储了数据的表个别是不能再简单通过phpmyadmin等管理工具处理的了。这个时候你需要两个工具，一个是mysql odbc 下载并按装mysql-connector-odbc-5.1.8-win32 一个是navicat for mysql。

第一步：控制面板->管理工具->数据源。在本地Windows下建立个mysql ODBC数据源，假设命名成visteel

第二步：打开Navicat for MySQL，单击“Connection”按钮设置连接。

第三步：连接上数据库服务器后右键单击数据库服务器选择“New Database…”新建一个数据库。记得“Character set”选定gbk；

第四步：选中要转换的表，将它们拖到新进的数据库中，在弹出的选项窗中选择“Copy here（Structure only）”,将数据表的结构复制到新数据库中；

第五步：在新建的数据库中选中刚导过来的所有的表，右键选择“Dump SQL File”导出成sql文件；

第六步：用文本编辑器打开刚导出的sql文件，将里面的DEFAULT CHARSET= 后面 不论是什么，全部替换成DEFAULT CHARSET=gbk，保存修改过的sql文件。

第七步：全选新建的数据库中的所有表，单击“Delete Table”删除。然后右键单击新建的数据库选择“Execute Sql File…”,找到并双击改过的sql文件，将改过的sql文件重新导回数据库中。

第八步：选中新建的数据库然后再点击：“Import Wizard”按钮。选择ODBC，点下一步。

第九步：点“Import From:”右边的“…”按钮，然后在“数据连接”属性窗口选择“连接”这一页，在“1、指定数据源”中选择在第一步中建立的数据源“visteel”；确定后返回“step 2 of 8”窗口，选中需要转换的表，或者点击“select all”按钮选择整个数据库的所有的表。连续点击三次“next”按钮后来到“Step 7 of 8”对话框。

第十步：选择“Copy：delete all records in destination,repopulate from the source”:再单击”next”来到“step 8 of 8”对话框。

第十一步：单击按钮“start”开始转换，直到出现信息“[Msg][lmp]Finished-Successfully”。

到此，数据库完美完成了GBK的整理。编辑XOOPS根目录下的mainfile.php文件，将define( 'XOOPS_DB_CHARSET', 'gb2312' )修改成define( 'XOOPS_DB_CHARSET', 'gbk' );

将本地数据库导出上传到虚拟主机进行测试，至此，mysq l#1366错误全部消失掉了。而且生僻汉字也不再是用？？显示了。