By Keeling on

I recently received "INSERT command denied" warnings when attempting to login a Drupal website. I suspected that my Database was full and I quickly confirmed my suspicion by checking my database administration page with 1&1.

Unable to login, I had no choice but to manually delete files from database tables. This of course reduced my database size to under the limit. However I continued to receive the "INSERT command denied" warnings and I was still unable to login the website.

Only after I changed my database password with 1&1 database administration and I correspondingly updated the settings.php file, was I finally able to login the website once again.

So here isa recap of how I recovered from "INSERT command denied" warnings

1. Reduced size of database by manually deleting files from database tables
2. Changed database password with database admin/control panel
3. Edited settings.php file to reflect new database password

I hope this saves someone a bit of time.

Best regards

⋅ Categories: Drupal 6.x

Comments

gardensgrey’s picture

gardensgrey commented

I am having the same problem on my message board as the one described and I can't figure out how to fix it.

My database is full, but I don't know what is safe to delete? I did empty the phpbb_sessions_keys table, but that didn't help (that's where I'm getting the error--when users try to login to the board).

It won't let me repair or optimize a lot of the tables for the same reason (INSERT command denied to user).

1. Which tables/files are safe to delete and how do I delete them (so I can get under the limit)?
2. Where is the settings.php file located?

Thanks to anyone that can help!

nigels’s picture

nigels commented

I am with One and one and had exactly the same problem.
The database had gone over the 100Mb limit at which point 1&1 restrict access and change the db password.

To free up some space in your database go into mysql admin and look at the sizes of each of the tables. You should be able to see which one is causing the problem. Mine was the "cache_menu" which had grown to 100Mb?

I cleared this table, reset the db password, and amended my settings.php file and now its all working again.

Thanks for the tip Keeling!

swapnilp’s picture

swapnilp commented

Thanks for the solution!
Even I faced similar problem with one of my very old drupal website. As suggested I applied same tricks

- Emptied Watchdog table as its size crossed 1 GB mark.
- Change db password and accordingly made changes to settings.php

And it allowed me to login.

Thanks!

podsnap’s picture

podsnap commented

Thank you, thank you, thank you!

I doubt I'd have ever tried this and was starting to get just a little stressed.

Thanks for taking the time to post this solution.

JustinCase76’s picture

JustinCase76 commented

Won't this table begin to fill up again over time? Is there a way to have drupal empty this table on a scheduled basis?

star98fm’s picture

star98fm commented

I know several years have gone by since this thread started, but I wanted to thank the posters above for providing the clues that led me to fix this same problem recently. I'll provide some details in the hope they might help someone else as well further down the road.

In my case, about a year ago 1&1 changed their actively supported version of php, which forced me to upgrade my site as well to avoid paying a steep monthly "extended support" fee. When this happened, a series of ugly red error message blocks beginning with the phrase "strict warning:" began appearing at the head of my site, referencing problems with a "views_handler" module. However, below the errors, everything looked fine. Having limited (ok, virtually nonexistent) expertise with php scripting in Drupal, instead of figuring out the root cause of the errors, I simply found the line in the script which was outputting them to the screen, and commented it out. Boom; errors stopped appearing, problem fixed (or so I thought at the time). What I now realize was that even though they were no longer being displayed, the errors were still being generated and inserted into the "watchdog" table of the sql database for my site. Eventually, they grew the sql to where it exceeded the maximum size limitation and started triggering the "Warning: insert command denied" error.

Following the steps above, I found the over-inflated database, and cleared the "watchdog" table completely. That reduced it to 4% of capacity, as opposed to the 150% it had been. I figured I next needed to change the database password and edit the settings.php file as noted, but thought first I'd completely log out and reload the site. Voila! To my surprise, everything looked fine again without needing to fiddle with the password. No doubt, new errors are being dumped into watchdog and sooner or later I'll have the same problem again, but the site is lightly used and it may take another year before the table fills up. And now at least I know what's causing it and how to fix it (temporarily, at least). Sooner or later I'll need to get around to rebuilding the entire site, but I need a much better knowledge of Drupal first before I can attempt this (I had a friend do most of the coding to begin with, who is now long gone). But hearty thanks to the authors of this thread, who gave me the nudge in the right direction.

Regards,

Alan
star98fm.net