I'm trying to debug an issue with a delete query not happening. I've added logging before the query, after the query and I'm logging the return value of the query. Everything looks right, the only problem is that the rows are still in the database.

It's a simple query, I can't see anything wrong with it:

$result = db_delete('cloud_files')
  ->condition('uri', $uri)

I've checked the $uri in every way I possibly can and it's right. I've tried executing the delete query by hand and it works just fine. The table name is correct, the field name is correct, the $uri is correct. I don't know what else to check.

I've used the Devel module to log the queries and while it logs queries that happen both before and after this query, it doesn't log this query at all. However, I've got error_log() calls before and after the query so I know this code is being run and it reports that it is running successfully.

I've even added code to select the data before deleting it and it works!

$select = db_select('cloud_files', 'cf')
                ->condition('uri', $uri)

$entry = $select->fetchAssoc();

error_log("entry: ".print_r($entry, true));

That works, it prints out the row I'm trying to delete.

dqp() doesn't work for delete queries, so I don't know of any way of getting the truly final sql being executed.

I've made sure that if I connect using the mysql command line client from the drupal host with the user/password in the drupal config that all of the commands work.

How do I debug this? What is going wrong?


Is there any kind of transaction happening during a delete action? Could this behavior be the result of those delete queries happening in a transaction that gets aborted?

  • You can cast the query object to a string before calling execute on it to get the raw SQL string, that might help to shed some light
    – Clive
    Commented Jul 19, 2012 at 0:29
  • I tried that, but it doesn't resolve the parameter replacements, so its not the real query. I've gotten sql statement you suggest above and plugged my values into it and it works, but that's not surprising. Commented Jul 19, 2012 at 1:48
  • 1
    Perhaps you could use some hook like hook_query_alter() to display the final query that will be executed? Commented Jul 19, 2012 at 4:14
  • @KristerAndersson: Delete queries don't invoke that hook.
    – Berdir
    Commented Jul 19, 2012 at 7:23
  • Wild stab in the dark...any chance you've created the table in question manually and forgotten to grant DELETE permissions to the user that Drupal is using to connect to the db? Also, try running a db_query('DELETE FROM...'); directly and see if you get the same problem. That runs a flat query string against the db, if it doesn't work I'd say the problem is with the MySQL server somewhere
    – Clive
    Commented Jul 19, 2012 at 7:49

2 Answers 2


With a problem like this, you may need to turn on MySQL query logging. Once logging is enabled, put a noticeable query right before and after your DELETE query (do you can have something easy to search for), check the logs, and go from there. Just be sure to disable logging when you are done. It can kill performance and also fill up the disk pretty quickly.

  • You can also enable the devel query log, that is as late as possible and allows to switch between displaying placeholders and the actual values.
    – Berdir
    Commented Jul 19, 2012 at 7:24
  • @KennyWyland mentioned using the Devel log already. This suggestion would be the next step to see what is actually going on.
    – mpdonadio
    Commented Jul 19, 2012 at 10:37
  • @KennyWyland, I take it you saw the transaction here and not the drupal devel log?
    – mpdonadio
    Commented Jul 19, 2012 at 17:06
  • I started trying to just trace through the node delete process and in node_delete() I saw the db_transaction() call. I didn't find it using the query logging, but I felt your answer was the actual answer to "how to debug a delete query in drupal" even though it wasn't the thing that truly solved my problem. Commented Jul 19, 2012 at 17:12

It turns out that my guess was right about a db transaction getting aborted. node_delete() begins a transaction and the action was being aborted after 2 minutes (there are a LOT of files to delete from CloudFiles and it took too long and the php process was killed). So, while the delete queries were issued, they were issued inside a transaction that got automatically rolled back.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.