- Attempted to connect my new Drupal 7 installation to a MySQL DB as a user without DROP permissions.
- Received error message about DROP permissions and gave the user correct permissions.
- Retried and received the following as the 'drupal_install_test'-DB was not created because it couldn't be previously dropped.
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.
Are you sure the configured username has the necessary permissions to create tables in the database?
That last message would send you in the wrong direction if the server isn't as kind as this one, giving the error quite clearly.
Perhaps the process that tests for CREATE & DROP permissions should check if the table already exists before attempting to create it again?
Comment | File | Size | Author |
---|---|---|---|
#37 | 1017050-37.patch | 2.25 KB | daffie |
Comments
Comment #1
David_Rothstein CreditAttribution: David_Rothstein commentedInteresting 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:
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 havedb_table_exists('drupal_install_test')
be the condition for that task, something along those lines.Comment #2
Crell CreditAttribution: Crell commentedTricksy...
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.
Comment #3
BerdirThese statements are defined in an array, so how would that conditional stuff work?
Comment #4
David_Rothstein CreditAttribution: David_Rothstein commentedI 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?
Comment #5
bryancasler CreditAttribution: bryancasler commentedAfter applying patch #4 I was still receiving the same error.
I decided to try deleting the "drupal_install_test" table. Now I am getting the following three errors.
As well as a fourth one below the main display.
Screenshot of the four errors. http://awesomescreenshot.com/0a27vfb7e
Comment #6
BerdirAre 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.
Comment #7
bryancasler CreditAttribution: bryancasler commentedI redid my install, no problems this time around. Could not reproduce this problem.
Comment #8
David_Rothstein CreditAttribution: David_Rothstein commented@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.
Comment #9
bryancasler CreditAttribution: bryancasler commentedI 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.
Comment #10
pcambraI'm getting the exact same error trying to update one site
Comment #11
xaccrocheur CreditAttribution: xaccrocheur commentedI'm getting this error whith a fresh 7.8 install... Somethings tells me that PDO doesnt like the "{}"s... Investigating
Comment #12
David_Rothstein CreditAttribution: David_Rothstein commented#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.
Comment #13
mkadin CreditAttribution: mkadin commentedTested #4 on drupal 7, works fine.
Re-rolled for drupal 8 and re-tested. Still works.
Comment #14
Guido64-1 CreditAttribution: Guido64-1 commentedFirst I recieved also above errors. After I gave the db user the necesary GLOBAL permissions like create drop etc Drupal install worked 100% (Drupal 7.12).
Comment #15
bib_boy CreditAttribution: bib_boy commentedI had the same issue upgrading from D6 to D7 and the patch at #4 worked for me. thanks.
Comment #16
bib_boy CreditAttribution: bib_boy commentedIn fact I just dropped the 'drop-table-test' table and clicked 'try again'...went past fine.
Comment #19
alansaviolobo CreditAttribution: alansaviolobo commentedComment #20
DuttonMa CreditAttribution: DuttonMa commentedComment #21
DuttonMa CreditAttribution: DuttonMa commentedD8 patch re-rolled, am working on D7 re-roll
Comment #22
Crell CreditAttribution: Crell commentedDon'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.
Comment #23
DuttonMa CreditAttribution: DuttonMa commentedD8 Patch re-worked to use Database class as suggested, thanks Crell
Comment #24
Crell CreditAttribution: Crell commentedSeems 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.)
Comment #27
DuttonMa CreditAttribution: DuttonMa commentedNew novice issue created https://www.drupal.org/node/2358147 and fixed
Comment #29
Crell CreditAttribution: Crell at Palantir.net commentedWow, this still passes. :-)
Comment #31
Crell CreditAttribution: Crell at Palantir.net commentedRerolling this should be Novice-friendly.
Comment #32
skelly CreditAttribution: skelly commentedRe-rolled by a novice...
Comment #33
Crell CreditAttribution: Crell at Palantir.net commentedThank you, Novice! :-)
Comment #34
alexpottWe can test this now by creating an InstallerTestBase test that creates the drupal_install_test before doing an interactive install.
Comment #35
aks22 CreditAttribution: aks22 commentedAfter changing permission of database user and restarting the server i got this worked.
Comment #37
daffie CreditAttribution: daffie commentedRerolled 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.
Comment #51
quietone CreditAttribution: quietone at PreviousNext commentedChecking 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!