如何實戰解決mysql#1366錯誤

仲介交易 HTTP://www.aliyun.com/zixun/aggregation/6858.html">SEO診斷 淘寶客 雲主機 技術大廳

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