Failing to grant 'Drop' privileges to db user during install locks install process without manual db cleanup

Interesting bug :) I think this will get more traction in the database system queue, so I'm moving it there.

The current query it runs is this:

CREATE TABLE {drupal_install_test} (id int NULL)

I don't know offhand if it's legal to simply add an IF NOT EXISTS to that (if all database drivers are expected to support that). If not, we could add some mechanism to skip running a database task if a certain condition returns TRUE, and have db_table_exists('drupal_install_test') be the condition for that task, something along those lines.

Tricksy...

I'd almost suggest running a table exists, and then either drop-create-drop or just create-drop, depending on the result. Either way we're testing both create and drop access.

These statements are defined in an array, so how would that conditional stuff work?

I like @Crell's idea of conditionally doing the drop-create-drop. It's a bit better than mine, since it means we will never skip testing CREATE.

I think something like the attached patch should work?

After applying patch #4 I was still receiving the same error.

Failed to CREATE a test table on your database server with the command CREATE TABLE {drupal_install_test} (id int NULL). The server reports the following message: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'drupal_install_test' already exists.

I decided to try deleting the "drupal_install_test" table. Now I am getting the following three errors.

Failed to UPDATE a value in a test table on your database server. We tried updating a value with the command UPDATE {drupal_install_test} SET id = 2 and the server reported the following error: SQLSTATE[42S02]: Base table or view not found: 1146 Table '394720_migrate2.drupal_install_test' doesn't exist.

Failed to DELETE a value from a test table on your database server. We tried deleting a value with the command DELETE FROM {drupal_install_test} and the server reported the following error: SQLSTATE[42S02]: Base table or view not found: 1146 Table '394720_migrate2.drupal_install_test' doesn't exist.

Failed to DROP a test table from your database server. We tried dropping a table with the command DROP TABLE {drupal_install_test} and the server reported the following error SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'drupal_install_test'.

As well as a fourth one below the main display.

Uncaught exception thrown in session handler.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => 2s9cstk1r9kf2itni42e6orkg0 [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 204 of C:\xampp\htdocs\includes\session.inc).

Screenshot of the four errors. http://awesomescreenshot.com/0a27vfb7e

Are you sure that you actually have these permissions (DELETE, UPDATE, DROP) in that database?

This issue is not about removing them, just handling the case nicely when you give those permissions after it told you about needing them.

I redid my install, no problems this time around. Could not reproduce this problem.

@animelion, you saw those error messages when installing a new Drupal 7 site, or when updating a Drupal 6 site to Drupal 7?

From the screenshot, it looks like you were updating a Drupal 6 site. If so, maybe the patch has some problem in that scenario. I'm not immediately sure what it would be, but I don't think I tested it in that scenario myself.

I think what happened is I tried updating from D6 to D7 and an error message was thrown. The update didn't appear to start but the "drupal_install_test" table was now added to the DB. From then on I could not get past the error messages stated in #5 no matter what I did. I went back and did a few other things that I can't recall, but one of them entailed me restoring the DB to a copy that was pre first upgrade attempt.

I'm getting the exact same error trying to update one site

I'm getting this error whith a fresh 7.8 install... Somethings tells me that PDO doesnt like the "{}"s... Investigating

#1389706: Failing to grant 'Drop' privileges to db user during install locks install process without manual db cleanup was duplicate, but had a better title.

Tested #4 on drupal 7, works fine.

Re-rolled for drupal 8 and re-tested. Still works.

I had the same issue upgrading from D6 to D7 and the patch at #4 worked for me. thanks.

In fact I just dropped the 'drop-table-test' table and clicked 'try again'...went past fine.

D8 patch re-rolled, am working on D7 re-roll

+++ b/core/lib/Drupal/Core/Database/Install/Tasks.php
@@ -304,5 +318,31 @@ public function validateDatabaseSettings($database) {
+    if (db_table_exists($table)) {

Don't call functions inside classes. Don't we have access to the connection object here? We can get the schema off of that. ($conn->getSchema()->tableExists()). If that's not possible then at the very least use the Database:: class to get it rather than the function.

D8 Patch re-worked to use Database class as suggested, thanks Crell

Seems reasonable to me, thanks!

It looks like runTestQuery() is also using a db_query(), even though it shouldn't. Can you open a new novice issue for that? (Or go ahead and fix that yourself in a new issue.)

New novice issue created https://www.drupal.org/node/2358147 and fixed

Wow, this still passes. :-)

Rerolling this should be Novice-friendly.

Re-rolled by a novice...

Thank you, Novice! :-)

We can test this now by creating an InstallerTestBase test that creates the drupal_install_test before doing an interactive install.

After changing permission of database user and restarting the server i got this worked.

Rerolled the patch.

We have now the Drupal\system\Tests\Installer\InstallerDatabaseErrorMessagesTest. This test installs the table drupal_install_test and tests if the correct erorr-message is displayed. With this patch that should no longer happen.

Checking in on this issue which hasn't has any work for 8 years to find out if it is still relevant.

Is this still relevant to Drupal 10?

Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Since it's been 6+ months going to close out. If still a valid issue in D11+ please reopen.