[SOLVED] After Upgrade - Restore Table to 3.9.24 and PHP 7.3 with error

3 years 2 months ago - 3 years 2 months ago #323361 by seagul30
Hi,

after the upgrade from Joomla 1.0 I am finally at 3.9.24.
However, in PHP 5.6.40 in my localhost the DB is ok.
If I transfer it with Akeeba Backup on localhost to a PHP 7.3.27 on restoring of the Database I get the SQL error:
#1118 - Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

I tried to transfer this table manuelly to the database, but I get the same error --> so, it is not Akeeba Backup.
How, do I need to change the table query to be able to import it?
The table has about 60 fields.
What can I do?

Thanks
Seagul

Please Log in to join the conversation.

3 years 2 months ago #323370 by krileon
I've no idea how Akeeba Backup restores tables. Your error doesn't state what table that's failing on either. I suggest contacting Akeeba Backup. You should not be hitting database row size limits with just 60 fields.


Kyle (Krileon)
Community Builder Team Member
Before posting on forums: Read FAQ thoroughly + Read our Documentation + Search the forums
CB links: Documentation - Localization - CB Quickstart - CB Paid Subscriptions - Add-Ons - Forge
--
If you are a Professional, Developer, or CB Paid Subscriptions subscriber and have a support issue please always post in your respective support forums for best results!
--
If I've missed your support post with a delay of 3 days or greater and are a Professional, Developer, or CBSubs subscriber please send me a private message with your thread and will reply when possible!
--
Please note I am available Monday - Friday from 8:00 AM CST to 4:00 PM CST. I am away on weekends (Saturday and Sunday) and if I've missed your post on or before a weekend after business hours please wait for the next following business day (Monday) and will get to your issue as soon as possible, thank you.
--
My role here is to provide guidance and assistance. I cannot provide custom code for each custom requirement. Please do not inquire me about custom development.

Please Log in to join the conversation.

3 years 2 months ago - 3 years 2 months ago #323371 by seagul30
Hi,
Thanks for your fast reply.

The error is on table #_comprofiler.
The restoration of the whole joomla setup works without that one table. I also tried exporting the table #_comprofiler on my PHP 5.4.60 and manually import it to PHP 7.3 on phpMyAdmin on my localhost.
But the error message is exactly the same.
So, there is a problem somewhere in the table.

The error message is:
#1118 - Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.


The SQL Statement is this:
---- Datenbank: `j39`---- ------------------------------------------------------------ Table structure for table `abcde_comprofiler`--
CREATE TABLE `abcde_comprofiler` (  `id` int(11) NOT NULL DEFAULT '0',  
`user_id` int(11) NOT NULL DEFAULT '0',  
`alias` varchar(150) DEFAULT NULL,  
`firstname` varchar(100) DEFAULT NULL,  
`middlename` varchar(100) DEFAULT NULL,  
`lastname` varchar(100) DEFAULT NULL,  
`hits` int(11) NOT NULL DEFAULT '0',  
`message_last_sent` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',  
`message_number_sent` int(11) NOT NULL DEFAULT '0',  
`avatar` varchar(255) DEFAULT NULL,  
`avatarapproved` tinyint(4) NOT NULL DEFAULT '1',  
`canvasposition` tinyint(4) NOT NULL DEFAULT '50',  
`canvasapproved` tinyint(4) NOT NULL DEFAULT '1',  
`canvas` varchar(255) DEFAULT NULL,  
`approved` tinyint(4) NOT NULL DEFAULT '1',  
`confirmed` tinyint(4) NOT NULL DEFAULT '1',  
`lastupdatedate` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',  
`registeripaddr` varchar(50) NOT NULL DEFAULT '',  
`cbactivation` varchar(50) NOT NULL DEFAULT '',  
`banned` tinyint(4) NOT NULL DEFAULT '0',  
`banneddate` datetime DEFAULT NULL,  
`unbanneddate` datetime DEFAULT NULL,  
`bannedby` int(11) DEFAULT NULL,  
`unbannedby` int(11) DEFAULT NULL,  
`bannedreason` mediumtext,  
`acceptedterms` tinyint(1) UNSIGNED NOT NULL DEFAULT '0',  
`acceptedtermsconsent` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',  
`address` varchar(255) DEFAULT NULL,  
`city` varchar(255) DEFAULT NULL,  
`zipcode` varchar(255) DEFAULT NULL,  
`cb_geschlecht` varchar(255) DEFAULT NULL,  
`cb_lieblingstag` mediumtext NOT NULL,  
`cb_persdaten` varchar(255) DEFAULT NULL,  
`cb_clubcardname` varchar(255) DEFAULT NULL,  
`cb_gebdat` date DEFAULT NULL,  
`cb_field` varchar(255) DEFAULT NULL,  
`cb_gocnamen` mediumtext,  
`cb_pgenable` varchar(255) DEFAULT NULL,  
`cb_pgautopublish` varchar(255) DEFAULT NULL,  
`cb_pgautoapprove` varchar(255) DEFAULT NULL,  
`cb_pgshortgreeting` varchar(255) DEFAULT NULL,  
`cb_pgtotalquotasize` varchar(255) DEFAULT NULL,  
`cb_pgtotalquotaitems` varchar(255) DEFAULT NULL,  
`cb_pguploadsize` varchar(255) DEFAULT NULL,  
`cb_pgtotalitems` varchar(255) DEFAULT NULL,  
`cb_pgtotalsize` varchar(255) DEFAULT NULL,  
`cb_pglastupdate` date DEFAULT NULL,  
`cb_pgaccessmode` varchar(255) DEFAULT NULL,  
`cb_pgdisplayformat` varchar(255) DEFAULT NULL,  
`cb_uebermich` mediumtext,  
`cb_nextlevel` varchar(255) DEFAULT NULL,  
`cb_suchen` mediumtext,  
`cb_motto` mediumtext,  
`cb_name` mediumtext,  
`cb_esknnensichnurgstedeslifestyleclubabcdefghiregistrieren` varchar(255) DEFAULT NULL,  
`cb_email` varchar(255) DEFAULT NULL,  
`cb_namepartner` mediumtext,  
`cb_pb_enable` varchar(255) DEFAULT NULL,  
`cb_pb_autopublish` varchar(255) DEFAULT NULL,  
`cb_pb_notifyme` varchar(255) DEFAULT NULL,  
`cb_ubermichuns` mediumtext,  
`cb_suche` mediumtext,  
`cb_geburtsdatum` date DEFAULT NULL,  
`cb_meinname` varchar(255) DEFAULT NULL,  
`cb_meinname2` varchar(255) DEFAULT NULL,  
`cb_meinbudy` varchar(255) DEFAULT NULL,  
`cb_geburtsdatum2` date DEFAULT NULL,  
`cb_nurfrmembers` varchar(255) DEFAULT NULL,  
`cb_stats` varchar(255) DEFAULT NULL,  
`cb_statsbuddy` varchar(255) DEFAULT NULL,  
`cb_interessean` mediumtext NOT NULL,  
`cb_status3` mediumtext,  
`cb_forumorder` text,  
`cb_forumview` text,  
`cb_forumsignature` mediumtext) ENGINE=InnoDB DEFAULT CHARSET=latin1

Do I need to change the Engine or charset?
Any other ideas?
Or which fields may cause the problem?

The whole installation is upgraded from 1.0 to 1.5 and to 3.9
All other extensions worked fine, just this one table gives me a headache.

[Edit:] I did not setup the whole CB, I just did the update, so I don't know why all fields are mediumtext - maybe that is the problem. [/Edit]

Thanks!
Seagul

Please Log in to join the conversation.

3 years 2 months ago #323373 by krileon
A lot of varchar and mediumtext were replaced by text. On the original install of your site run the "Check Community Builder User Fields Database with strict column types" tool in CB > Tools to migrate field column types before doing the Akeeba Backup. Your charset is also not compatible with Joomla. The CHARSET should be utf8 and your database collation should be changed to utf8mb4_unicode_ci.

It doesn't look like you've enough fields to be causing this problem though.


Kyle (Krileon)
Community Builder Team Member
Before posting on forums: Read FAQ thoroughly + Read our Documentation + Search the forums
CB links: Documentation - Localization - CB Quickstart - CB Paid Subscriptions - Add-Ons - Forge
--
If you are a Professional, Developer, or CB Paid Subscriptions subscriber and have a support issue please always post in your respective support forums for best results!
--
If I've missed your support post with a delay of 3 days or greater and are a Professional, Developer, or CBSubs subscriber please send me a private message with your thread and will reply when possible!
--
Please note I am available Monday - Friday from 8:00 AM CST to 4:00 PM CST. I am away on weekends (Saturday and Sunday) and if I've missed your post on or before a weekend after business hours please wait for the next following business day (Monday) and will get to your issue as soon as possible, thank you.
--
My role here is to provide guidance and assistance. I cannot provide custom code for each custom requirement. Please do not inquire me about custom development.
The following user(s) said Thank You: seagul30

Please Log in to join the conversation.

3 years 2 months ago #323378 by seagul30
great! Thanks!
The "Check Community Builder User Fields Database with strict column types" tool did the trick!

I could import the table now :-)
The following user(s) said Thank You: krileon

Please Log in to join the conversation.

Moderators: beatnantkrileon
Time to create page: 0.204 seconds

Facebook Twitter LinkedIn