升级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 + 插件长字段的问题以及一些难以在升级程序规避的问题，至于非标的话确实没啥办法。
毕竟不可能每碰到一个孤例就去写个针对性的检测和规避代码，通用升级程序很难做到这一点，只能对大量站点遇到的普遍性的问题做提前检测或者线上规避。
不太清楚您站点规模，但我们的确建议建站时使用较低版本软件的站点、中大型、超大型站点或二次开发、第三方插件模板较多的站点进行一次或多次本地升级演练，并准备足够可行的回退方案和回退时间，以免升级时因意外导致升级失败且无法按时回退导致的问题。