Hi,

Following db_insert query fails:
$insert = db_insert($indexer_table)
->fields(array('entity_id', 'bundle', 'status', 'entity_type', 'changed'))
->from($select);
->execute();

All other db_inserts run ok, but if it uses a from then it fails with:
DatabaseTransactionNoActiveException: in DatabaseConnection->rollback() (line 1016 of drupal\includes\database\database.inc).

Comments

ron_ron’s picture

Thank you for advice.

Kind regards
Ron

ron_ron’s picture

Hi find the line where the error occures

include\database\oracle\query.inc line 60
at: $this->connection....

if (count($this->insertValues)==0) // all default query
$last_insert_id = $this->connection->query($stmt, array(), $this->queryOptions);

Kind regards,
Ron

Unitoch’s picture

Issue summary: View changes

I ran into this error as well. I can shed some more light on this.

Steps to reproduce:
1. Install and use the Oracle driver.
2. Install and configure a Solr server and use the Solr module to connect it to your Drupal site.
3. Go to admin/config/search/apachesolr/settings/apache_solr/index and try to reindex your content. You'll get the error.

This is happening because of a query that the Apache Solr module is issuing. It's trying to issue the following query:

INSERT INTO "APACHESOLR_INDEX_ENTITIES_NODE" (entity_id, bundle, status, entity_type, changed) SELECT n.nid AS entity_id, n.type AS bundle, n.status AS status, 'node' AS entity_type, 1405458910 AS changed
FROM 
"NODE" n
WHERE  (status = :db_condition_placeholder_0) AND (n.type IN  (:db_condition_placeholder_1, :db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4, :db_condition_placeholder_5, :db_condition_placeholder_6, :db_condition_placeholder_7, :db_condition_placeholder_8, :db_condition_placeholder_9, :db_condition_placeholder_10, :db_condition_placeholder_11, :db_condition_placeholder_12, :db_condition_placeholder_13, :db_condition_placeholder_14))

What's happening is that the arguments are not correctly bound to the PDOStatement object when it's ultimately getting run. The arguments are there correctly in query.inc, and they're getting bound to the $stmt object on line 53:

    if (!empty($this->fromQuery)) {
      foreach ($this->fromQuery->getArguments() as $key => $value) {
        $stmt->bindParam($key, $value);
      }
    }

But, the bound values aren't correctly being reflected in the final query. I got around it by doing some dirty hacking, passing the arguments to the query function just after that.

  if (count($this->insertValues)==0) // all default query
    {
      $arguments = $this->fromQuery->getArguments();

      // Hack: Binding doesn't always seem to be sufficient to pass arguments
      $last_insert_id = $this->connection->query($stmt,  $arguments, $this->queryOptions);
    }

And then also hacking database.inc to use that array instead of bound variables.

        // Hack: Use args when Solr is trying to reindex
        if (strpos($query->queryString, 'APACHESOLR_INDEX_ENTITIES_NODE') !== FALSE) {
          $stmt->execute($args);
        }
        else {
          $stmt->execute(NULL);
        }

This kind of hacking is, of course, horrible in many ways and will kill kittens.

I'm guessing this is an edge case, using a select inside an insert and binding the variables to the select. Maybe that's why the error is happening?

bohart’s picture

Version: 7.x-1.12 » 7.x-1.x-dev
Status: Active » Closed (outdated)

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

Everyone can apply the patches/suggestions above (not tested by the maintainers, tested by the community) to their D7 projects.
If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.

Thanks!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.