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

申請創業報道，分享創業好點子。點擊此處，共同探討創業新機遇！

總結

以上是生活随笔為你收集整理的mysql 1366in_如何实战解决mysql#1366错误的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。