升級X3.5常見問題匯總

shaxin

湖中沉 發表于 2023-1-6 15:17
小云插件的數據表設計不支持innodb的規范，需要修改他的數據表使其支持

老大說一說怎么修改支持吧。這個長短，改成190就可以了。改了后，如果這個表是插件的，不是在258個表以內的，往后面在，序列化數據轉換   這一步一樣會出問題的。對于沒有插件數據表的X3.4升級應該是沒有問題的。

湖中沉

shaxin 發表于 2023-1-6 16:07
老大說一說怎么修改支持吧。這個長短，改成190就可以了。改了后，如果這個表是插件的，不是在258個表以內 ...

并不會，實際測試只要符合長度，并不報錯，報錯就是其他問題。你的問題已經給你回答過多次了，別人情況跟你完全是不同的

shaxin

湖中沉 發表于 2023-1-6 16:11
并不會，實際測試只要符合長度，并不報錯，報錯就是其他問題。你的問題已經給你回答過多次了，別人情況跟 ...

我也遇到他這樣的，改成190就可以了。

Kilo

Q004：升級Ucenter 7.0時顯示數據庫members表里缺少email這個字段
A004：標準Ucenter必定存在email字段的，此提示一般是以前某些修改導致email字段不存在或未被設置為索引，進入數據表（使用PhpMyAdmin）將pre_ucenter_members表的email字段設置為索引后再升級。
--------------
如何使用phpMyAdmin設置表字段為索引
https://jingyan.baidu.com/article/a378c96071fa73f2282830f2.html

解決了，感謝。

Kilo

Q008：升級過程中提示(1061) Duplicate key name 'gpmid'ALTER TABLE common_member_grouppm ADD INDEX gpmid(gpmid);
A008：應該是升級出錯后又直接再次執行升級文件導致的，升級出錯后建議回滾數據后再重新操作。同時，針對該問題，回滾數據后可以進入“pre_common_member_grouppm”數據表檢查索引gpmid是否存在，如存在，可以先予以刪除再操作升級
---------------------
直接刪除不掉，可以將索引gpmid改名為123，然后繼續升級動作。
然后會再生成一個索引gpmid，這個時候再把123刪除掉就可以了

ink

shaxin 發表于 2023-1-6 16:07
老大說一說怎么修改支持吧。這個長短，改成190就可以了。改了后，如果這個表是插件的，不是在258個表以內 ...

我也遇到類似你的問題了，出錯信息也是說某個表不存在，如下：

Discuz! Database Error
(1146) Table '.pre_common_member_profile_history' doesn't exist
SHOW COLUMNS FROM pre_common_member_profile_history;


實際這個表存在的，并且已經轉換成innodb了，只是表的名字不一樣，數據庫中實際的表名為：

disccommon_member_profile_history

我的數據表的表前綴是 disc


上面提示的出錯信息中也是出現了  .pre_  正確的話應該是disc

老周部落

ink 發表于 2023-1-17 22:37
我也遇到類似你的問題了，出錯信息也是說某個表不存在，如下：

Discuz! Database Error

數據表的表前綴正常來說應該帶下劃線的，這個您得先查下代碼了，看是否是沒兼容下劃線。

ink

老周部落 發表于 2023-1-18 06:56
數據表的表前綴正常來說應該帶下劃線的，這個您得先查下代碼了，看是否是沒兼容下劃線。 ...

感謝你的答復，我弄到半夜2、3點，解決了，這個表應該是之前歲月里面哪個應用或者其他什么留下的，刪除了再升級即可。后面陸續遇到了7、8個這樣的問題，每次都是回滾，然后進數據庫刪除相關的表，最后再來……

discuz能否制作一款在本地對數據庫升級或者檢測的工具軟件，凡是這類不合規的或者不在范圍的內表全部刪除。

否則按照現在這種方式，失敗出錯了就得回滾數據重來真的有點累啊，網站數據量大并且建站時間比較久的話，這樣的操作簡直堪比噩夢……


好的地方就是ucenter和discuz是分開升級的，減少了重復的步驟。

ink

shaxin 發表于 2023-1-4 10:00
沒有刪錯，里面有這個表的

把這些提示出錯不存在的表全部刪除，這個升級程序有個小小的BUG，就是1146出錯后，提示不存在表名時不會包含你的表前綴，只會顯示成discuz標準的表名。

忽略你自己的表前綴，匹配一下就好，找到了就刪除，然后回滾數據庫，再來……如此重復直到刪除全部多余的表即可升級完成。


就是有點累人，如果數據庫很小那還湊合，如果數據庫很大就是噩夢級別了，所以我在想如果是很大的數據庫的話，是否可以先刪除一些帖子數據，縮小數據庫的體積，然后升級，解決了所有出錯信息后，記錄下來，恢復原先的大數據庫，按照先前的記錄處理完畢，最后升級。

老周部落

ink 發表于 2023-1-18 10:38
感謝你的答復，我弄到半夜2、3點，解決了，這個表應該是之前歲月里面哪個應用或者其他什么留下的，刪除了 ...

我們有計劃做檢測，但主要是針對低版本 MySQL + 插件長字段的問題以及一些難以在升級程序規避的問題，至于非標的話確實沒啥辦法。
畢竟不可能每碰到一個孤例就去寫個針對性的檢測和規避代碼，通用升級程序很難做到這一點，只能對大量站點遇到的普遍性的問題做提前檢測或者線上規避。
不太清楚您站點規模，但我們的確建議建站時使用較低版本軟件的站點、中大型、超大型站點或二次開發、第三方插件模板較多的站點進行一次或多次本地升級演練，并準備足夠可行的回退方案和回退時間，以免升級時因意外導致升級失敗且無法按時回退導致的問題。