WBB4 -> WSC5 Import Error on User Groups

  • Affected Version
    WoltLab Suite 5.5

    Hi all,

    Currently trying to upgrade a WBB4 forum to WSC5, and I'm getting the following error when importing user groups:

    Not too sure what's going on here, so any help is much appreciated!

  • The import target is a fresh installation of the software or does it already contain data? Also, can you please check the values for wcfN_user_group.groupType in the source database, in particular look out for values that are less than 4. There should be only values in the range of 1, 2 and 3. Are there any other values present?

  • Thanks for the reply.

    The target contains a small amount of data, but only a couple of test posts and users. Should I use a completely fresh install?

    In the source table you asked for, there's one group each with 1, 2 or 3. The rest are all 4s.

  • Should I use a completely fresh install?

    No, that’s fine. Keep in mind that you need to wipe any test data before performing the actual import, otherwise all IDs will get shifted. This is not really an issue for a test run though, but I would still recommend it.

    In the source table you asked for, there's one group each with 1, 2 or 3. The rest are all 4s.

    Okay, that is perfectly fine. Can you please check the target database too? The types 1, 2 and 3 should appear exactly one, all other groups should have a value of 4 or higher.

    The error message that you’ve provided pointed to a mismatch of the group ids with a type of 1, 2 or 3 which in practice should never happen. These are builtin types that are part of the software’s inner workings.

  • No, that’s fine. Keep in mind that you need to wipe any test data before performing the actual import, otherwise all IDs will get shifted. This is not really an issue for a test run though, but I would still recommend it.

    Okay, that is perfectly fine. Can you please check the target database too? The types 1, 2 and 3 should appear exactly one, all other groups should have a value of 4 or higher.

    The error message that you’ve provided pointed to a mismatch of the group ids with a type of 1, 2 or 3 which in practice should never happen. These are builtin types that are part of the software’s inner workings.

    Ah, I think that might be the problem. There are no groups of type 1, 2 or 3 in the target DB. We had an issue a couple of days ago that caused the server to unexpectedly shutdown - I'm wondering if the database got corrupted in the process.

    Would it be easiest just to start again with a fresh target install?

  • Hi

    I'm wondering if the database got corrupted in the process.

    Correctly handling powerloss situations is a key feature of InnoDB and from my experience InnoDB either returns the correct data or actively detects corruption and intentionally crashes the MySQL server process to avoid making things worse.

    I strongly recommend you check your logs and config, this type of silent data corruption must never happen and might indicate serious issues with your hardware or file system – unless you accidentally configured InnoDB in “eat my data” mode.

  • Thanks all for your help so far. I think we've tracked down the original fault that led to the data corruption and system failure to a fault drive which our host really should have picked up on earlier and notified us about.

    I've since performed a new import on a new, completely clean WSC5 installation. That import completed without any issues, however I'm now getting a similar error when trying to rebuild the data (specifically, the post data).

    I've already performed the same check Alexander suggested earlier - in the target DB (which now contains all of the imported data), there is one group each of 1, 2, 3 and 9. The rest are all 4s.

    I'm unsure what could have gone wrong here - I believe I've done everything "by the book", and as I said there were no errors at all during the import process. Any help is much appreciated!

  • That’s odd, you shouldn’t be running into this issue in the latest release of 5.5.

    It is caused by a cache issue with the CLI environment and does not imply any data corruption. You can reset the cache once through the admin panel and then start php cli.php again.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!