Hello

Und ewig grüßt das Murmeltier … Groundhog Day again.

I tried the update like written in the subject and experienced two issues. Both issues break the update and leave the database in a state which is not working for the old version.

1. the update script printed out "Database error in line 452: Specified key was too long; max key length is 767 bytes" and the update did not finish.
I noticed that this issue was discussed already, and I also did some googeling. Probably this isuue is somehow related to an old SQL version, in my case it is "Server version: 5.5.62 MySQL Community Server (GPL)", i.e. I agree with the explanation from user Auge.

I did not really understand if there is already a bugfix. If yes, it looks like it did not work properly. Maybe the best solution is a SQL update.

Yes, I thought I fixed it. But when this problem encountered for you with the latest available version 20220803.1, it obviously doesn't work in every case.

2. just for fun i tried a quick-and-dirty hack (not recommended for others). I changed in the update script line 448 "VARCHAR(256)" to "VARCHAR(255)", because 3 * 255 < 768.

I will check, if this is an appropriate way, a.k.a. a not so quick-and-dirty hack as you think, to solve the issue. I solved the same issue with setting the charset to utf8 (without the appendix mb4). That way the maximum index length does not exceed because of the different charset. But it was obviously the wrong place to do this.

And indeed, this error was gone, but another appeared: "Database error in line 452: Duplicate entry 'abcdef@domain.tld' for key 'key_user_email'". It turned out that there are two different usernames with the same email address.
Thats a case of a bad administration, in the first place I will remove the double entry.

I don't know, if this is really a case of a "bad administration". Until version 20220508.1 (2.5.0) it was simply possible to add more than one account with the same e-mail-address. I for myself used this possibility regulary for testing purposes.

It's a trap when updating to a version in the 2.5 branch.

But I think it should checked before updating or at least mentioned in the update hints.

Yes, you are right.

Once we changed the collation of the column username in the userdata table because the database found the name "Hans" and the fictive name "Häns" to be identical. The update script tested the database for such pseudoidentical values, to enforce the admin to solve the problem in collaboration with the affected users before the update.

This time (making the e-mail-address unique) we didn't checked the values for doublettes. That is a failure. I will have to completely rework the update script.

I installed the backup of my current forum, so there is no damage and I can prepare the next try without stress. While installing the database backup I noticed the new version added four tables. i.e. PREFIX-akismet_rating, PREFIX-b8_rating, PREFIX-b8_wordlist, and PREFIX-uploads.
It turned out that these tables remained in the database after installing the backup and caused errors at the next try.

Hmm. The update script doesn't check for already existing tables. Normally this will not happen, but in your case with a previoulsy partially failed upgrade, it will fail.

I would suggest to offer some short fallback hints in the update description, maybe:
"Before update: back up database and php/html code.
If it did not work:
replace code with your backup
replace database with your backup
delete the newly added tables, if still present"

ACK

Tschö, Auge