By iKaruS_KS on

Hi folks.

I’ve been trying to upgrade from Drupal 7 to Drupal 8 for a little while now (lost too many weekend to this!).

I’m getting the following error: “Source database does not contain a recognizable Drupal version”. I’ve been googling this error for a while to see if there is an obvious issue, but without any luck.

I’ve done a fresh install of Drupal 8.8.6 on a CentOS 8 host, and I’m migrating from Drupal 7.70 running on a CentOS 7 host.

I’ve tried two methods to access the SQL data.  SQLdump, and import the database into the new host’s database, and opening the firewall to try and access the old database directly. Both produce the same results. I’m passing the global root account, but have also tried the account details configured in my settings.php file.

I (think) I’m only running core modules on both the old and new platforms.

I’ve installed MyPHPadmin and it appears that there are no database prefixes configured (caveat, I don’t really know what I’m doing!).

I’ve looked at the system table, and can see that the schema version is not consistent across all the entries in the “schema version” column (unsure if it should be). (e.g.  modules/field/modules/list/tests/list_test.module = -1; modules/block/block.module = 7009).  I’m leaning towards this being the problem, but I have no real clue.

In case it's relevant, the Drupal 7 platform was originally built on Drupal 6.

Any ideas on how to resolve this error?

⋅ Categories: Drupal 7.x

Comments

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

The databases for Drupal 8 and Drupal 7 are different.  You need to look into Migrate programs ... there are several modules involved and a lot of careful reading and experimentation to do.  Jeff Geerling has posted a recent set of videos re. the Migrate process. Ummm ...
 

https://www.jeffgeerling.com/blog/2020/migrating-jeffgeerlingcom-drupal-...

plus there is plenty of documentation on Drupal.org.  A lot of the stuff is confusing because migration (in my view) is a work in progress.  You'll find different versions (releases) of the modules and Drush and only some of them will work with each other. 

You can't do what you are trying to do ... just move the database over.

iKaruS_KS’s picture

iKaruS_KS commented

Hi fkelly,

Thanks for the link. I'll have a look after work tonight.

Unfortunately, I don't have drush working on either the old or new servers (spent an afternoon trying to get it working, but gave up i the end).

I did manage to use SQLdump to migrate a copy of the D7 database into the new server, but when trying to import/migrate the content into the D8 instance I get the message I mentioned in my initial post (Source database does not contain a recognizable Drupal version).

As both you and mmjvb have suggested it, I'll keep trying to import using this method.

mmjvb’s picture

mmjvb commented

Good idea to get the dataset across to the database server of your D8 installation. Finding the system table in phpMyAdmin could mean there is no prefix specified. To verify you would check the settings.php of the d7 site, only to make sure. When using table specific prefixing you are out of luck. Suggest to change tables to using the same prefix.

The version should be different, could be the same. That version is a recording of the [module]_update_#### found in .install of each module. -1 meaning it is no longer installed/enabled. 7009 means there is a block_update_7009 in block.install, which is the last function executed when running update.php or drush up. So, this is not the problem.

What is the version for the module system? It is expected to start with 7.

What database server and version are you using? Even for MySQL 8 you shouldn't have an issue getting to the system table of d7. It is D8 accessing D7 tables. 

iKaruS_KS’s picture

iKaruS_KS commented

Hi mmjvb,

You gave me a 'doh' moment when you suggested I look at the settings.php file. I've done that, and can confirm that no prefix is set.

Thanks explaining how the version numbers work for the modules.

If i understood your question correctly, the 'modules/system/system.module' has a Schema_Version value of 7082.

On the new host, I'm running MariaDB Server version 10.3.22-MariaDB (old server is running 5.5.65-MariaDB).

(edit to fix server version).

mmjvb’s picture

mmjvb commented

Leaves not finding table system. Are you sure your connection to d7 dataset is where you imported the data?

Don't know for 10.2.22 MariaDB, but it could be refusing system due to being reserved word. Probably easiest when altering tables to use prefix so there are no reserved words as table name. Suggest "d7" as prefix, both tables and connection in settings.php.

Is there an error reported in Recent log messages (admin/reports/dblog) ? 

iKaruS_KS’s picture

iKaruS_KS commented

I've had a look at the values in the database i'm trying to import (using phpMyAdmin). Definitely looking at the right database. I'll look into what the table system is tonight.

I configured the Database Logging module to 'log All messages, with backtrace information' but don't get any output in the Upgrade Log (when trying the migrate process again).

I believe you are probably correct about the table name.  I need to look into the process of bulk changes to the prefix using phpMyAdmin (it looks easy enough, but want to make sure I'm doing it right).  Won't have time to tinker for a day or two.

Thanks for your advice.

iKaruS_KS’s picture

iKaruS_KS commented

The upgrade was successful.

While I can't be certain as to the exact cause, I suspect this problem relates to reserved word use within later versions of MySQL / MariaDB. See post 12 here: https://www.drupal.org/node/2637870

I used the instructions here to add a table prefix (D7 in my case):

https://thebarton.org/remove-change-database-table-prefix/

[instructions copied in case the link breaks down the track]

How to change a database table prefix

  1. Log into phpMyadmin
  2. Select the database you wish to work with
  3. Click on the “Structure” tab; all or most of your tables should be listed
  4. Go to bottom of screen, click on “Check all”
  5. Change the select box next to it and select “Replace Table Prefix”
  6. A modal will popup
    1. In From, enter your old prefix
    2. In To, enter your new prefix
    3. Click “Continue” button
  7. Wait for phpMyAdmin to finish

In short, while no prefix was set, i needed to configure one in order for Drupal 8 to import the old Drupal 7 databases.

Big thanks to mmjvb and fkelly for helping me understand this.

mmjvb’s picture

mmjvb commented

Thanks for the procedure to change prefix in phpMyAdmin. Didn't know you could do that, learning every day!

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

I'm not sure that I was much help at all.  mmjvb correct me if I'm wrong but isn't the database structure of Drupal 7 very different from that of Drupal 8?  See:

https://www.drupal.org/docs/8/upgrade/upgrading-from-drupal-6-or-7-to-dr...

where it states:  "Drupal 8 significantly changed the way content and configuration is stored in the database. Because of this, an update can't simply be applied to an existing Drupal 6/7 site. Instead, the content and configuration data from the Drupal 6/7 site must be migrated to a new Drupal 8/9 site."  and that a migration must be run.

If you could just import a Drupal 7 database into Drupal 8, migration would not be necessary. 

mmjvb’s picture

mmjvb commented

And it does require a migration. The error reported is about connection to d7. To migrate, you run d8 migrations pointing to d7 connection. That connection must work and recognize the d7 as such. To eliminate infrastructure issues you can move the data to the database server used by d8. Your choice to restore d7 data in a separate database or use prefix in same as d8 database. As far as migration is concerned there is no difference. My preference would be separate databases. Despite that the prefix can solve the reserved words issue. You might even go for both.

Having d7 data on same database server/database is not the same as import. Import would suggest making it available as d8 data. That is not the case here. You make the d7 data available to d8 migration, which uses it as d7 data, to convert it to d8 data.

Obviously, both d7 data and d8 data must be available to d8 migration. My understanding is that d8 migration doesn't have an issue with reserved words as table name, but I could be wrong about that. Using proper prefix would solve it, as mentioned by OP.

@fkelly Sounds like we agree. Hopefully provided more context. Still consider this helpful !