Score:1

While upgrading from D6, update.php appears to expect the Drupal 7 version of the database array and it throws errors

et flag

Leaving settings.php in place (but writeable), per instructions 13 + 14 of major upgrade section of https://api.drupal.org/api/drupal/UPGRADE.txt/7.x , with the new D7 codebase but the old D6 DB, i get the following errors:

Notice: Undefined offset: 0 in Database::parseConnectionInfo() (line 1529 of [...]includes/database/database.inc).
Notice: Undefined index: driver in Database::openConnection() (line 1681 of [...]includes/database/database.inc).
Notice: Undefined index: driver in Database::openConnection() (line 1681 of [...]/includes/database/database.inc).
DatabaseDriverNotSpecifiedException: Driver not specified for this database connection: default in Database::openConnection() (line 1682 of [...]includes/database/database.inc).
Notice: Undefined index: driver in Database::openConnection() (line 1681 of [...]includes/database/database.inc).
The website encountered an unexpected error. Please try again later.

Here is the core of the question -- according to the instructions, and normal upgrades, update.php should note that settings.php is D6-style, and change it to D7-style, including db-connection format.

It is not doing so. What could be going wrong? Reading through the script, it determines the DB schema... but it's not obvious to me where it determines the settings.php version and updates it. Help? Thanks!

The installed Drupal 6 release is 6.38, the latest release for Drupal 6.

I first tried to upgrade to Drupal 7.95; then I tried to upgrade to Drupal 7.34, and then again with Drupal 7.0, but I had the same issue.

[[Note: the below is not part of the core of this question, but responds to "why don't you just hardcode D7-style DB connection? I can hard-code the database settings using the Drupal 7 array structure, but that leads to other problems (expecting things that don't exist yet):

Error
Error message
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal_7_test.main_system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module ) in drupal_get_installed_schema_version() (line 151 of [...]/includes/install.inc).
The website encountered an unexpected error. Please try again later.

Per this report, my assumption is that this means the code is expecting the new D7 codebase because the database connection was D7 style: https://www.drupal.org/node/1308308 ]]

id flag
What instructions? With Drupal 6 being end of life for many years Drupal 7 moved on. In this case you must update the database connection settings to the current Drupal 7 standard, shown in the example settings file. It should take all of a minute to do.
john brush avatar
et flag
Thanks so much for your reply! Really appreciate it. I agree that Drupal 6 is exotically out of date, and know that it is casting back into the dim recesses of memory. These are the instructions I am following: the canonical UPGRADE.txt in every codebase of D7: https://api.drupal.org/api/drupal/UPGRADE.txt/7.x -- specifically items 13 and 14 of the "major version upgrade" section. As originally noted, the first thing I tried was to handcode the db connection, and then I get different error, indicating what appears to be a missing DB, which I assume is because the upgrade didn't happen.
id flag
Drupal Answers is a "one question at a time" site rather than a support forum. And those instructions say this, even for minor updates: "Copy the custom and site-specific entries from the backup you made into the new settings.php file. You will definitely need the lines giving the database information, and you will also want to copy in any other customizations you have added." This question is likely to be closed as lacking focus. Tables like `main_something` being missing suggests you have a table prefix configured.
apaderno avatar
us flag
Point #14 says: *Make your settings.php file writeable, so that the update process can convert it to the format of Drupal 7.x*. It is the update process that converts it to the Drupal 7 format, as long as the file is writable from the server.
apaderno avatar
us flag
As a side note, there is not a *minor version upgrade* and a *major version upgrade*. In Drupal terminology, passing from Drupal 6 to Drupal 7 is an upgrade. *Major version upgrade* just puts the emphasis on the fact that the major version number (the *7* in ***7**.95*) changes (for example, passing from ***6**.38* to ***7**.95*). If it is the minor version number that changes (for example, passing from _7.‎ㅤ**34**_ to _7.ㅤ**95**_), that is an update, not an *minor version upgrade*.
john brush avatar
et flag
to @cilefen -- thanks for the input on the format of this forum. i edited the above to include a more detail regarding why simply hardcoding the database connection in the D7 format doesn't work. i can remove it again to focus on the specific question -- why is the update.php script unable to parse the D6-style url-based database connection that remains in the D6 settings.php?
john brush avatar
et flag
to @apaderno you are absolutely correct about point #14, and the expected behavior. this is the kernel of the question -- why might this not be happening in my case? it should happen, but for some reason update.php is not reading the url-style database connection (which has all required detail and worked fine in D6), and is not changing it to D7 format.
Score:1
et flag

The script update.php ascertains whether settings.php is D6 or D7 based on whether the $databases array is set. If that array is set in any form, it will skip all code designed to work with Drupal 6 settings file, and will skip upgrading the database to Drupal 7.

In my case, integration with CiviCRM required a bit of a kludgy addition to the settings.php creating aliases for databases, and used the $databases variable to do it. This confused update.php.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.