On 2/19/2025 at 2:13 PM, th3madcap said:

Is there a way to have the SQL structure?

You can also take the table structure from the database backup file.

I cannot revert it anymore, I have the dump of the data and another dump of structure + data but the "CREATE TABLE" omit the default value for the field

CREATE TABLE rc_core_sys_conf_settings (

conf_id int(10) NOT NULL,

conf_key varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',

conf_value mediumtext COLLATE utf8mb4_unicode_ci,

conf_default text COLLATE utf8mb4_unicode_ci,

conf_keywords text COLLATE utf8mb4_unicode_ci,

conf_app varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,

conf_plugin bigint(20) UNSIGNED DEFAULT NULL,

conf_report enum('full','bool') COLLATE utf8mb4_unicode_ci DEFAULT NULL

) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Is the structure of the database the same for all the versions?

I mean, can I make a fresh install of 7.4.20 , then I dump into it the content of my actual DB, board 4.3.5 ?

The core_sys_conf_settings table should be the same for all 4.x versions. I don't remember any changes to it at least. 🙄

  On 2/19/2025 at 2:56 PM, th3madcap said:

Is the structure of the database the same for all the versions?

There are database changes between the version that you are currently using and version 4.7.20, but I don't know if that's the case with the aforementioned table. The best way to make really sure is to take the schema from your backup file, that is if you made one before the change

  On 2/19/2025 at 2:56 PM, th3madcap said:

I mean, can I make a fresh install of 7.4.20 , then I dump into it the content of my actual DB, board 4.3.5 ?

Yes, you can. However a couple of things will be required as well. First is to make sure that php and MySQL meet the 4.7.20 requirements. Then you will have to run the upgrader to bring the database up to date as well, so it matches the forum files. Another thing to keep in mind is that your third party stuff might not be compatible with the newest version.

.

  On 2/19/2025 at 3:10 PM, Miss_B said:

There are database changes between the version that you are currently using and version 4.7.20, but I don't know if that's the case with the aforementioned table. The best way to make really sure is to take the schema from your backup file, that is if you made one before the change

I have the schema in sql format but I suspect that the default value issue is the same for all tables, this is why I'm asking a dump of the correct schema of 4.3.5 version, where I can import my data and proceed to the update.

But if 4.7.20 version uses the same database as 4.3.5 I can dump my data in a fresh installation.

  On 2/19/2025 at 3:46 PM, th3madcap said:

I have the schema in sql format but I suspect that the default value issue is the same for all tables, this is why I'm asking a dump of the correct schema of 4.3.5 version, where I can import my data and proceed to the update.

But if 4.7.20 version uses the same database as 4.3.5 I can dump my data in a fresh installation.

They will absolutely not be the same, no

  On 2/19/2025 at 3:46 PM, th3madcap said:

But if 4.7.20 version uses the same database as 4.3.5 I can dump my data in a fresh installation.

As mentioned previously, they aren't the same. You will have to run the upgrader afterwards.

Yes, but it doesn't work.

My Database schema is missing the default values for some field, I need a way to put online the board, then proceed to the update, but first I need to go online with a working DB.

At this point I think I have two only chances:

• Install a fresh 4.3.5 that re-create a blank database with correct schema where I can upload my contents,

• A SQL with the schema of v4.3.5 Database

Is there a way to have an archived version of 4.3.5 installation?

Is core_sys_conf_settings the only "broken" table? Or do you have more?

I don't know and I don't want to make changes to the current DB, I mean, I can change the property of the ID to autoincrement but I think I will have the same error on the next table and I don't think it's a good idea

  On 2/20/2025 at 7:14 AM, th3madcap said:

I don't know and I don't want to make changes to the current DB, I mean, I can change the property of the ID to autoincrement but I think I will have the same error on the next table and I don't think it's a good idea

If you back up the table and try, you have nothing to lose. The issue here is you appear not to have taken a backup prior to starting this originally, is that correct?

I have made a backup before, but it seems that the autoincrement property was not included, here is the create table instance for that table

CREATE TABLE rc_core_sys_conf_settings (

conf_id int(10) NOT NULL,

conf_key varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',

conf_value mediumtext COLLATE utf8mb4_unicode_ci,

conf_default text COLLATE utf8mb4_unicode_ci,

conf_keywords text COLLATE utf8mb4_unicode_ci,

conf_app varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,

conf_plugin bigint(20) UNSIGNED DEFAULT NULL,

conf_report enum('full','bool') COLLATE utf8mb4_unicode_ci DEFAULT NULL

) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

We need to reverse back here a bit. You started by saying the admin CP says to 'fix this', which indeed it does, but it will break things. However that is the answer to your issue if your database is missing anything. Are you just assuming it will break things, or have you tried it?

OK, after some days I have fixed the tables of my DB, now my board is running with MySQL 8 and PHP7.4

Now I have MySQL 8.0 and PHP7.4.

If I switch to PHP8.0 or PHP8.1 I have a 500 Error so I can't upgrade to 4.7.20

Actually the opposite is true. You would need to upgrade manually and have to update to 8.1 in order to upgrade to 4.7.20. You cant upgrade using the auto upgrader.

  On 2/18/2025 at 12:13 PM, Marc said:

1. Upload the latest requirement checker, and check your server meets minimum requirements (you absolutely would be using PHP 8.1 if you are upgrading to the latest version of 4)

2. Upload a fresh set of files, downloaded from your client area. You should not need to be reuploading uploads or anything, as you should be merging, not replacing entirely

3. Run the upgrader from /admin/upgrade (manually visit that URL)

OK, so I have to upload the new files to the root, then switch to 8.1 then admin/upgrade, right?

Thats correct, yes. Make sure you take a full backup and can switch anything you change back, so you can easily revert if you need to

I have this error while upgrading

Specified key was too long; max key length is 1000 bytes
/web/htdocs/www.radiochitarra.it/home/applications/core/setup/upg_104000/upgrade.php::427

Edited February 25Feb 25 by th3madcap

That would usually indicate you aren't using INNODB. I would suggest checking that issue first of all

All went well!

Thank you to everyone in this thread

Excellent. Very glad to hear you got to the latest 4 :)