SMN_Admin

I had to change a lot of data types to convert everything to utf8mb4 the script in the AdminCP did a great work. After that the Update Script gave us the right queries again to repair the things I changed. Long story short, the update worked and the DB is now utf8mb4. Thanks!

Hey Marc, we did a health check before that, but thanks for reminding us! As Miss_B already mentioned is the database itself a problem, but as we only have a chroot webspace the database is out of our scope and we have to get in touch with our hosting provider. We get the error: Sorry, you do not have permission for that! 4C171/4 The database could not be converted. Contact your hosting provider or system administrator for assistance. Specified key was too long; max key length is 1000 bytes But again, I think our hosting provider has to do here his thing.

The forum itself was not working anymore due to a corrupt database. The error in the database was xxx.smn_core_modules_new Error : Incorrect key file for table 'smn_core_modules_new'; try to repair it error : Corrupt That still happens if I try to execute the query in one go. I have to break it down in smaller queries. And because the the web gui dosn't check if the new tables is working before it drops the old one we had a corrupt database.

As we tried our updates to v4.7.15 we got some errors with the database and that there are 'some' fixes required. And while trying to do the fixes with the web gui it broke our complete forum. Lesson learned, I will take my time for the updates, but now with the update v4.7.16 it seems like urgent to do the update and we still have the issue with the database and even with manually adding the mysql statements it seems not to fix the problem, as the messages are the same even if I do some of the queries. We are on a self hosted version at a webspace hoster. Database Version 8.0.36-28 UPDATE `smn_core_modules` SET `sys_module_title`='' WHERE `sys_module_title` IS NULL; UPDATE `smn_core_modules` SET `sys_module_application`='' WHERE `sys_module_application` IS NULL; UPDATE `smn_core_modules` SET `sys_module_key`='' WHERE `sys_module_key` IS NULL; CREATE TABLE `smn_core_modules_new` LIKE `smn_core_modules`; ALTER TABLE `smn_core_modules_new` CHANGE COLUMN `sys_module_title` `sys_module_title` VARCHAR (32) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '' , DROP INDEX `identifier`, DROP INDEX `sys_module_application`, CHANGE COLUMN `sys_module_application` `sys_module_application` VARCHAR (32) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '' , ADD UNIQUE KEY `identifier` (`sys_module_application`,`sys_module_key`,`sys_module_area`), ADD KEY `sys_module_application` (`sys_module_application`), DROP INDEX `sys_module_key`, CHANGE COLUMN `sys_module_key` `sys_module_key` VARCHAR (32) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '' , ADD KEY `sys_module_key` (`sys_module_key`), CHANGE COLUMN `sys_module_area` `sys_module_area` VARCHAR (32) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT 'front' , CHANGE COLUMN `sys_module_default_controller` `sys_module_default_controller` VARCHAR (32) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL ; INSERT IGNORE INTO `smn_core_modules_new` SELECT * FROM `smn_core_modules`; DROP TABLE `smn_core_modules`; RENAME TABLE `smn_core_modules_new` TO `smn_core_modules`; This is only one of the blocks, but it seems like it wants to do it for all of the tables. So my questions are: Will these only be updated, after all queries are done? And can this be an issue with our hosters db and how to fix this, that we can update our forum?

Yes, the results are the same. It's looking like the task isn't performed. I tried it again, identified 587 members, started the process, got the response "members are queing", but did not find any backgrpound process by switching immediately to the dashboard. I have no idea how long it will take to make that move of 587 members, but after having waited for 20 minutes i still can't recognize any movements. Can a potential error come from a wrong format in date selection? As you may see system tells me to use the German format (dd.mm.yyyy): Is this input correctly transferred to American dates (mm.dd.yyyy)? By the way, I could not find any settings in ACP to change it.

Task seems to be completed: But if I look at the number of members with the new primary group "usr2JahrInaktiv" I find only three pages: But according to my first post the number should be bigger, around 600 members, listed on more than these 3 pages. so it seems that the task was not running.

Hello, I wanted to move members that weren't active on our forum for a while to another primary group instead of their original one. I set this filtering and got a list of nearly 600 members, have chosen "Move members Found", could specify the new target primary target group, got a last warning "This will move 587 memebers", and started the job. System responds with "Members queing", so it was looking well at the first glance. But when I checked the content of the new primary group those members weren't moved, they still have their old primary group. Can anyone tell me what went wrong here? Best regards Juergen