Syntax error or access violation: 1118 Row size too large #15648
Steps to reproduce
Finish the change collation of all tables.
Errors out when changing the Collation of table
Updated from an older Nextcloud/ownCloud or fresh install:
List of activated apps:
Are you using external storage, if yes which one: local
Are you using encryption: no
Are you using an external user-backend, if yes which one: No
Nextcloud log (data/nextcloud.log)
The text was updated successfully, but these errors were encountered:
I've tried running the SQL query manually:
The table seems to have most columns set to VARCHAR:
I'm not sure which rows should I manually change to TEXT. Any advice?
Meanwhile, my instance is stuck in maintenance mode. I can't use my system. I'm not sure how to revert this besides restoring a backup.
What version of MariaDB are you using? Since your last post suggests taht you got SSH access, you can just enter
Depending on what version you are using (I guess it's below 10.2), there may be a configuration issue.
Connect to your Database as you did in your last post and issue the following command and post your result:
Mine for example is:
Ok, I would suggest setting these two variables to what mine are (mentioned in my post):
Sine your config contains the variable
If that shouldn't work, you can do the conversion manually like so:
This will create a list of
So I can't change those variables like that.
Regarding running the repair.... that's what's triggering my problem. When running the occ:
That's actually weird but could well be that I missed the memo where it says, that these can only be set via the
Try adding the following parameters to your
And restart your MySQL/MariaDB
If you now issue the following command, it should not show NULL anymore but the actual value:
Config set, and I get the values now.
I think there is still an issue with the
Now it's up to you what you are going to use, depending on how much data you have and how often this data is being accessed. I went for DYNAMIC instead of COMPRESSED as I don't really have any space issues.
To change the
After executing the set of statements, you should be able to execute the repair command without any issue now.
I've managed to solve this by changing the
After this the
Same problem here with table oc_activity (and only with that table). The proposed workaround to modify column message and file allowed us to fully convert to utf8mb4.
I really wish, we wouldn't need such dirty tricks to prevent problems that have been reported (and confirmed) more than a year ago.